From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
kent.overstreet@gmail.com, dm-devel@redhat.com,
linux-kernel@vger.kernel.org,
"Alasdair G. Kergon" <agk@redhat.com>
Subject: Re: [PATCH v2] block: flush queued bios when the process blocks
Date: Tue, 6 Oct 2015 16:26:06 -0400 [thread overview]
Message-ID: <20151006202606.GB4158@redhat.com> (raw)
In-Reply-To: <20151006201637.GA4158@redhat.com>
On Tue, Oct 06 2015 at 4:16P -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> To give others context for why I'm caring about this issue again, this
> recent BZ against 4.3-rc served as a reminder that we _need_ a fix:
> https://bugzilla.redhat.com/show_bug.cgi?id=1267650
>
> FYI, I cleaned up the plug-based approach a bit further, here is the
> incremental patch:
> http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip&id=f73d001ec692125308accbb5ca26f892f949c1b6
>
> And here is a new version of the overall combined patch (sharing now
> before I transition to looking at alternatives, though my gut is the use
> of a plug in generic_make_request really wouldn't hurt us.. famous last
> words):
>
> block/bio.c | 82 +++++++++++++-------------------------------------
> block/blk-core.c | 21 ++++++++-----
> drivers/md/dm-bufio.c | 2 +-
> drivers/md/raid1.c | 6 ++--
> drivers/md/raid10.c | 6 ++--
> include/linux/blkdev.h | 11 +++++--
> include/linux/sched.h | 4 ---
> 7 files changed, 51 insertions(+), 81 deletions(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index ad3f276..3d03668 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -354,35 +354,31 @@ static void bio_alloc_rescue(struct work_struct *work)
> }
> }
>
> -static void punt_bios_to_rescuer(struct bio_set *bs)
> +/**
> + * blk_flush_bio_list
> + * @plug: the blk_plug that may have collected bios
> + *
> + * Pop bios queued on plug->bio_list and submit each of them to
> + * their rescue workqueue.
> + *
> + * If the bio doesn't have a bio_set, we use the default fs_bio_set.
> + * However, stacking drivers should use bio_set, so this shouldn't be
> + * an issue.
> + */
> +void blk_flush_bio_list(struct blk_plug *plug)
> {
> - struct bio_list punt, nopunt;
> struct bio *bio;
>
> - /*
> - * In order to guarantee forward progress we must punt only bios that
> - * were allocated from this bio_set; otherwise, if there was a bio on
> - * there for a stacking driver higher up in the stack, processing it
> - * could require allocating bios from this bio_set, and doing that from
> - * our own rescuer would be bad.
> - *
> - * Since bio lists are singly linked, pop them all instead of trying to
> - * remove from the middle of the list:
> - */
> -
> - bio_list_init(&punt);
> - bio_list_init(&nopunt);
> -
> - while ((bio = bio_list_pop(current->bio_list)))
> - bio_list_add(bio->bi_pool == bs ? &punt : &nopunt, bio);
> -
> - *current->bio_list = nopunt;
> -
> - spin_lock(&bs->rescue_lock);
> - bio_list_merge(&bs->rescue_list, &punt);
> - spin_unlock(&bs->rescue_lock);
> + while ((bio = bio_list_pop(&plug->bio_list))) {
Bleh, should be plug->bio_list.. obviously I didn't compile test this...
Here is the incremental I've folded in:
diff --git a/block/bio.c b/block/bio.c
index 3d03668..b868b9e 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -369,7 +369,10 @@ void blk_flush_bio_list(struct blk_plug *plug)
{
struct bio *bio;
- while ((bio = bio_list_pop(&plug->bio_list))) {
+ if (!plug->bio_list)
+ return;
+
+ while ((bio = bio_list_pop(plug->bio_list))) {
struct bio_set *bs = bio->bi_pool;
if (!bs)
bs = fs_bio_set;
next prev parent reply other threads:[~2015-10-06 20:26 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 15:03 [PATCH] block: flush queued bios when the process blocks Mikulas Patocka
2014-05-27 15:08 ` Jens Axboe
2014-05-27 15:23 ` Mikulas Patocka
2014-05-27 15:42 ` Jens Axboe
2014-05-27 16:26 ` Mikulas Patocka
2014-05-27 17:33 ` Mike Snitzer
2014-05-27 19:56 ` Kent Overstreet
2015-10-05 19:50 ` Mike Snitzer
2014-05-27 17:42 ` [PATCH] " Jens Axboe
2014-05-27 18:14 ` [dm-devel] " Christoph Hellwig
2014-05-27 19:59 ` Kent Overstreet
2014-05-27 19:56 ` Mikulas Patocka
2014-05-27 20:06 ` Kent Overstreet
2014-05-29 23:52 ` Mikulas Patocka
2015-10-05 20:59 ` Mike Snitzer
2015-10-06 13:28 ` Mikulas Patocka
2015-10-06 13:47 ` Mike Snitzer
2015-10-06 14:10 ` Mikulas Patocka
2015-10-06 14:26 ` Mikulas Patocka
2015-10-06 18:17 ` [dm-devel] " Mikulas Patocka
2015-10-06 18:50 ` Mike Snitzer
2015-10-06 20:16 ` [PATCH v2] " Mike Snitzer
2015-10-06 20:26 ` Mike Snitzer [this message]
2015-10-08 15:04 ` Mikulas Patocka
2015-10-08 15:08 ` Mike Snitzer
2015-10-09 19:52 ` Mike Snitzer
2015-10-09 19:59 ` Mike Snitzer
2015-10-14 20:47 ` [PATCH v3 for-4.4] block: flush queued bios when process blocks to avoid deadlock Mike Snitzer
2015-10-14 21:44 ` Jeff Moyer
2015-10-17 16:04 ` Ming Lei
2015-10-20 19:57 ` Mike Snitzer
2015-10-20 20:03 ` Mikulas Patocka
2015-10-21 16:38 ` Ming Lei
2015-10-21 21:49 ` Mikulas Patocka
2015-10-22 1:53 ` Ming Lei
2015-10-15 3:27 ` [PATCH v2] block: flush queued bios when the process blocks Ming Lei
2015-10-15 8:06 ` Mike Snitzer
2015-10-16 3:08 ` Ming Lei
2015-10-16 15:29 ` Mike Snitzer
2015-10-17 15:54 ` Ming Lei
2015-10-17 15:54 ` Ming Lei
2015-10-09 11:58 ` kbuild test robot
2014-05-27 17:59 ` [PATCH] " Kent Overstreet
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=20151006202606.GB4158@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.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.