linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	Eric Wheeler <dm-devel@lists.ewheeler.net>,
	Christoph Hellwig <hch@lst.de>,
	dm-devel@redhat.com, johnstonj.public@codenest.com,
	linux-block@vger.kernel.org
Subject: Re: dm-crypt: Fix error with too large bios
Date: Mon, 29 Aug 2016 14:19:41 -0400	[thread overview]
Message-ID: <20160829181940.GA21794@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1608271102560.14465@file01.intranet.prod.int.rdu2.redhat.com>

On Sat, Aug 27 2016 at 11:09am -0400,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> 
> 
> On Fri, 26 Aug 2016, Mike Snitzer wrote:
> 
> > On Thu, Aug 25 2016 at  4:13pm -0400,
> > Jens Axboe <axboe@kernel.dk> wrote:
> > 
> > > On 08/25/2016 12:34 PM, Mikulas Patocka wrote:
> > > >
> > > >Device mapper can't split the bio in generic_make_request - it frees the
> > > >md->queue->bio_split bioset, to save one kernel thread per device. Device
> > > >mapper uses its own splitting mechanism.
> > > >
> > > >So what is the final decision? - should device mapper split the big bio or
> > > >should bcache not submit big bios?
> > > >
> > > >I think splitting big bios in the device mapper is better - simply because
> > > >it is much less code than reworking bcache to split bios internally.
> > > >
> > > >BTW. In the device mapper, we have a layer dm-io, that was created to work
> > > >around bio size limitations - it accepts unlimited I/O request and splits
> > > >it to several bios. When bio size limitations are gone, we could simplify
> > > >dm-io too.
> > > 
> > > The patch from Ming Lei was applied for 4.8 the other day.
> > 
> > See linux-block commit:
> > 4d70dca4eadf2f block: make sure a big bio is split into at most 256 bvecs
> > http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=4d70dca4eadf2f95abe389116ac02b8439c2d16c
> 
> But this patch won't work for device mapper, blk_bio_segment_split is 
> called from blk_queue_split and device mapper doesn't use blk_queue_split 
> (it can't because it frees queue->bio_split).
> 
> We still need these two patches:
> https://www.redhat.com/archives/dm-devel/2016-May/msg00211.html
> https://www.redhat.com/archives/dm-devel/2016-May/msg00210.html

I'm left wondering whether it'd be better to revert commit dbba42d8a9e
("dm: eliminate unused "bioset" process for each bio-based DM device")

And also look for other areas of DM that could leverage the block core's
relatively new splitting capabilities.

Otherwise, we'll just be sprinking more BIO_MAX_PAGES-based splitting
code in DM targets because DM is so "special" that it doesn't need the
block core's splitting (even though it clearly would now benefit).

Mike

  parent reply	other threads:[~2016-08-29 18:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LRH.2.11.1608102050200.10662@mail.ewheeler.net>
     [not found] ` <alpine.LRH.2.02.1608131342250.3291@file01.intranet.prod.int.rdu2.redhat.com>
     [not found]   ` <20160814000740.GA5317@redhat.com>
     [not found]     ` <alpine.LRH.2.02.1608151245120.13026@file01.intranet.prod.int.rdu2.redhat.com>
     [not found]       ` <alpine.LRH.2.11.1608181742260.10662@mail.ewheeler.net>
2016-08-25 18:34         ` [dm-devel] dm-crypt: Fix error with too large bios Mikulas Patocka
2016-08-25 20:13           ` Jens Axboe
2016-08-26 14:05             ` Mike Snitzer
2016-08-27 15:09               ` Mikulas Patocka
2016-08-29  5:22                 ` Ming Lei
2016-08-29 21:57                   ` Mikulas Patocka
2016-08-30  7:33                     ` Ming Lei
2016-08-30 12:19                       ` Mikulas Patocka
2016-08-30 20:57                         ` Mike Snitzer
2016-08-30 22:27                           ` Mikulas Patocka
2016-08-31  6:26                             ` Milan Broz
2016-08-31 13:39                               ` Mike Snitzer
2016-08-29 18:19                 ` Mike Snitzer [this message]
2016-08-29 22:01                   ` Mikulas Patocka

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=20160829181940.GA21794@redhat.com \
    --to=snitzer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@lists.ewheeler.net \
    --cc=dm-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=johnstonj.public@codenest.com \
    --cc=linux-block@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).