public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Zach Brown <zach.brown@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-aio@kvack.org
Subject: Re: [PATCH take2 3/5] dio: formalize bio counters as a dio reference count
Date: Tue, 3 Oct 2006 15:44:49 -0700	[thread overview]
Message-ID: <20061003154449.daab5dbd.akpm@osdl.org> (raw)
In-Reply-To: <20061002232135.18827.28686.sendpatchset@tetsuo.zabbo.net>

On Mon,  2 Oct 2006 16:21:35 -0700 (PDT)
Zach Brown <zach.brown@oracle.com> wrote:

> dio: formalize bio counters as a dio reference count
> 
> Previously we had two confusing counts of bio progress.  'bio_count' was
> decremented as bios were processed and freed by the dio core.  It was used to
> indicate final completion of the dio operation.  'bios_in_flight' reflected how
> many bios were between submit_bio() and bio->end_io.  It was used by the sync
> path to decide when to wake up and finish completing bios and was ignored
> by the async path.
> 
> This patch collapses the two notions into one notion of a dio reference count.
> bios hold a dio reference when they're between submit_bio and bio->end_io.
> 
> Since bios_in_flight was only used in the sync path it is now equivalent
> to dio->refcount - 1 which accounts for direct_io_worker() holding a 
> reference for the duration of the operation.
> 
> dio_bio_complete() -> finished_one_bio() was called from the sync path after
> finding bios on the list that the bio->end_io function had deposited.
> finished_one_bio() can not drop the dio reference on behalf of these bios now
> because bio->end_io already has.  The is_async test in finished_one_bio() meant
> that it never actually did anything other than drop the bio_count for sync
> callers.  So we remove its refcount decrement, don't call it from
> dio_bio_complete(), and hoist its call up into the async dio_bio_complete()
> caller after an explicit refcount decrement.  It is renamed dio_complete_aio()
> to reflect the remaining work it actually does.
> 
> ...
>  
> +static int wait_for_more_bios(struct dio *dio)
> +{
> +	assert_spin_locked(&dio->bio_lock);
> +
> +	return (atomic_read(&dio->refcount) > 1) && (dio->bio_list == NULL);
> +}

This function isn't well-named.

> @@ -1103,7 +1088,11 @@ direct_io_worker(int rw, struct kiocb *i
>  		}
>  		if (ret == 0)
>  			ret = dio->result;
> -		finished_one_bio(dio);		/* This can free the dio */
> +
> +		/* this can free the dio */
> +		if (atomic_dec_and_test(&dio->refcount))
> +			dio_complete_aio(dio);

So...  how come it's legitimate to touch *dio if it can be freed by now? 
(iirc, it's legit, but a comment explaining this oddity is needed).


  reply	other threads:[~2006-10-03 22:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-02 23:21 [PATCH take2 0/5] dio: clean up completion phase of direct_io_worker() Zach Brown
2006-10-02 23:21 ` [PATCH take2 1/5] dio: centralize completion in dio_complete() Zach Brown
2006-10-03 22:26   ` Andrew Morton
2006-10-03 23:05     ` Zach Brown
2006-10-02 23:21 ` [PATCH take2 2/5] dio: call blk_run_address_space() once per op Zach Brown
2006-10-02 23:21 ` [PATCH take2 3/5] dio: formalize bio counters as a dio reference count Zach Brown
2006-10-03 22:44   ` Andrew Morton [this message]
2006-10-03 23:23     ` Zach Brown
2006-10-02 23:21 ` [PATCH take2 4/5] dio: remove duplicate bio wait code Zach Brown
2006-10-02 23:21 ` [PATCH take2 5/5] dio: only call aio_complete() after returning -EIOCBQUEUED Zach Brown
2006-10-03 21:47 ` [PATCH take2 0/5] dio: clean up completion phase of direct_io_worker() Jeff Moyer
2006-10-03 22:20 ` Andrew Morton
2006-10-03 23:00   ` Zach Brown
2006-10-04 10:12     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061003154449.daab5dbd.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zach.brown@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox