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).
next prev parent reply other threads:[~2006-10-03 22:44 UTC|newest]
Thread overview: 16+ 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-02 23:21 ` 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 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.