From: Christoph Hellwig <hch@infradead.org>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Christoph Hellwig <hch@infradead.org>,
target-devel <target-devel@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] target/iblock: Fix double iblock_complete_cmd callback bug
Date: Fri, 16 Nov 2012 14:25:41 -0500 [thread overview]
Message-ID: <20121116192541.GA25096@infradead.org> (raw)
In-Reply-To: <1353018990.11597.35.camel@haakon2.linux-iscsi.org>
On Thu, Nov 15, 2012 at 02:36:30PM -0800, Nicholas A. Bellinger wrote:
> However, setting the default ibr->pending=2 value before dispatch, and
> making a extra iblock_complete_cmd() call from iblock_execute_rw(),
> while doing the normal iblock_complete_cmd() calls from
> iblock_bio_done() is AFAICT a pointless extra atomic_dec_and_test() call
> per I/O.
>
> Was there a reason why you changed ->pending from 1 -> 2 during the
> se_task removal in commit 5787cacd0bd5ee01..?
It is to avoid having the request completed before even submitting all
bios. As soon as one is submitted it could on a very fast device
complete before we've incremented the count for the next bio.
It's a very common scheme used all over the kernel when submitting
I/O in smaller subdivisions.
> So the case this patch tries to avoid is where iblock_submit_bio() is
> called multiple times before the final ibr->pending value is set, this
> could potentially cause bios completion calls to decrement the value +
> complete to core before iblock_execute_rw() is done incrementing
> ibr->pending.
That's exacltly what we try to avoid here.
> How about returning an exception here instead when IBLOCK_MAX_BIOS in
> reached..?
Why? As soon as we kicked the first batch off we're guaranteed to make
progress allocating more as sson as the first of the submitted ones
completes.
> Btw, where did the default of 32 for this come from..?
It's a random number, with the important property that it's considerably
smaller than IBLOCK_BIO_POOL_SIZE.
prev parent reply other threads:[~2012-11-16 19:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-08 19:58 [PATCH] target/iblock: Fix double iblock_complete_cmd callback bug Nicholas A. Bellinger
2012-11-15 10:49 ` Christoph Hellwig
2012-11-15 22:36 ` Nicholas A. Bellinger
2012-11-15 22:50 ` Nicholas A. Bellinger
2012-11-16 19:25 ` Christoph Hellwig [this message]
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=20121116192541.GA25096@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=target-devel@vger.kernel.org \
/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.