All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@canonical.com>
To: Shaohua Li <shli@fb.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>,
	Jeff Moyer <jmoyer@redhat.com>, Jens Axboe <axboe@fb.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Eric Wheeler <bcache@lists.ewheeler.net>,
	Sebastian Roesner <sroesner-kernelorg@roesner-online.de>,
	"4.2+" <stable@vger.kernel.org>
Subject: Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs
Date: Wed, 6 Apr 2016 09:05:39 +0800	[thread overview]
Message-ID: <CACVXFVOnrnpgdYT_2RQ=BEZFa1V5ZQXvF6dAskuwB5vMVeEU9A@mail.gmail.com> (raw)
In-Reply-To: <20160406005951.GA3129698@devbig084.prn1.facebook.com>

On Wed, Apr 6, 2016 at 8:59 AM, Shaohua Li <shli@fb.com> wrote:
> On Tue, Apr 05, 2016 at 04:45:55PM -0800, Kent Overstreet wrote:
>> On Tue, Apr 05, 2016 at 05:41:47PM -0700, Shaohua Li wrote:
>> > On Tue, Apr 05, 2016 at 04:36:04PM -0800, Kent Overstreet wrote:
>> > > On Tue, Apr 05, 2016 at 05:30:07PM -0700, Shaohua Li wrote:
>> > > > this one:
>> > > > http://marc.info/?l=linux-kernel&m=145926976808760&w=2
>> > >
>> > > Ah. that patch won't actually fix the bug, since md isn't using
>> > > blk_default_limits, it's using blk_set_stacking_limits().
>> >
>> > Not really, the limit is set by under layer disk not md, otherwise it
>> > should be BLK_SAFE_MAX_SECTORS, but the reported bio has 2560 sectors.
>> > blk_set_stacking_limits() will use it.
>>
>> What? Well, that could should just be deleted, there's no reason anymore for md
>> to care about the queue limits of the devices underneath it.
>>
>> Regardless, using BLK_DEF_MAX_SECTORS to limit # of pages in the biovec is
>> _crazy_. Why would you even do that? We have a separate field in queue limits
>> for # max segments, use it.
>
> We don't limit the max segments in blk_queue_max_segments(), but we can
> add. On the other hand, limit max segments to 256 could be a problem,
> because bvec page isn't always 4k, this might make some bio smaller.

It is nothing with max segments limit, it is about max sectors limit:
think about one big bio which includes 2Mbytes, then 512 bvecs are required,
but the 2M buffer can be continuous physically.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-04-06  1:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 17:44 [PATCH] block: make sure big bio is splitted into at most 256 bvecs Ming Lei
2016-04-05 18:27 ` Shaohua Li
2016-04-06  0:27   ` Kent Overstreet
2016-04-06  0:30     ` Shaohua Li
2016-04-06  0:36       ` Kent Overstreet
2016-04-06  0:41         ` Shaohua Li
2016-04-06  0:45           ` Kent Overstreet
2016-04-06  0:59             ` Shaohua Li
2016-04-06  1:05               ` Ming Lei [this message]
2016-04-06  0:47   ` Ming Lei
2016-04-06  1:04     ` Shaohua Li
2016-04-06  1:11       ` Ming Lei
2016-04-06  0:30 ` Kent Overstreet
2016-04-06  0:59   ` Ming Lei
2016-04-06  1:10     ` Kent Overstreet
2016-04-06  1:20       ` Ming Lei
2016-04-06  1:28         ` Kent Overstreet
2016-04-06  1:51           ` Ming Lei
2016-04-06  2:22             ` Kent Overstreet
2016-04-06  2:30               ` Ming Lei
2016-04-06  2:34                 ` Kent Overstreet
2016-04-06  2:37                   ` Ming Lei
2016-04-06  2:40                     ` Kent Overstreet
2016-04-06  2:51                       ` Ming Lei
2016-04-06  2:58                         ` Kent Overstreet
2016-04-06  1:02 ` Ming Lei
2016-04-07  1:48   ` Eric Wheeler
2016-04-07  1:36 ` Eric Wheeler
2016-04-07  1:49   ` Ming Lei
2016-04-07  1:56     ` Eric Wheeler
2016-04-07  2:16       ` Ming Lei
2016-04-07 23:29         ` Eric Wheeler
2016-04-08  0:21           ` Ming Lei

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='CACVXFVOnrnpgdYT_2RQ=BEZFa1V5ZQXvF6dAskuwB5vMVeEU9A@mail.gmail.com' \
    --to=ming.lei@canonical.com \
    --cc=axboe@fb.com \
    --cc=bcache@lists.ewheeler.net \
    --cc=hch@infradead.org \
    --cc=jmoyer@redhat.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shli@fb.com \
    --cc=sroesner-kernelorg@roesner-online.de \
    --cc=stable@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.