Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1366865

Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big

Show all headers | View raw

On Wed, Mar 30, 2016 at 09:39:35AM +0800, Ming Lei wrote:
> On Wed, Mar 30, 2016 at 12:42 AM, Shaohua Li <shli@fb.com> wrote:
> > bio_alloc_bioset() allocates bvecs from bvec_slabs which can only
> > allocate maximum 256 bvec (eg, 1M for 4k pages). We can't bump
> > BLK_DEF_MAX_SECTORS to exceed this value otherwise bio_alloc_bioset will
> > fail.
> >
> > In the future, we can extend the size either bvec_slabs array is
> > expanded or the upcoming multipage bvec is added if pages are
> > contiguous. This one is suitable for stable.
> >
> > Fixes: d2be537c3ba (block: bump BLK_DEF_MAX_SECTORS to 2560)
> > Reported-by: Sebastian Roesner <sroesner-kernelorg@roesner-online.de>
> > Cc: stable@vger.kernel.org (4.2+)
> > Cc: Ming Lei <ming.lei@canonical.com>
> > Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
> > Signed-off-by: Shaohua Li <shli@fb.com>
> > ---
> >  include/linux/blkdev.h | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index 7e5d7e0..da64325 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/linux/blkdev.h
> > @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
> >  enum blk_default_limits {
> >         BLK_MAX_SEGMENTS        = 128,
> >         BLK_SAFE_MAX_SECTORS    = 255,
> > -       BLK_DEF_MAX_SECTORS     = 2560,
> > +       /*
> > +        * if you change this, please also change bvec_alloc and BIO_MAX_PAGES.
> > +        * Otherwise bio_alloc_bioset will break.
> > +        */
> > +       BLK_DEF_MAX_SECTORS     = BIO_MAX_SECTORS,
> 
> Thinking about it further, it isn't good to change the default max
> sectors because
> the patch affects REQ_PC bios too, which don't have the 1Mbytes limit at all.

what breaks setting REQ_PC to 1M limit? I can understand bigger limit might help
big raid array performance, but REQ_PC isn't the case.

> So suggest to just change bcache's queue max sector limit to 1M, that means
> we shouldn't encourage bcache's usage of bypassing bio_add_page().

Don't think this is a good idea. This is a limitation of block core,
block core should make sure the limitation doesn't break, not the
driver. On the other hand, are you going to fix all drivers? drivers can
set arbitrary max sector limit.

Thanks,
Shaohua

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Shaohua Li <shli@fb.com> - 2016-03-29 18:50 +0200
  Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Christoph Hellwig <hch@infradead.org> - 2016-03-29 23:20 +0200
    Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Shaohua Li <shli@fb.com> - 2016-03-30 00:10 +0200
      Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Christoph Hellwig <hch@infradead.org> - 2016-03-30 09:00 +0200
        Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Shaohua Li <shli@fb.com> - 2016-03-30 19:00 +0200
          Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Christoph Hellwig <hch@infradead.org> - 2016-03-30 19:50 +0200
          Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Kent Overstreet <kent.overstreet@gmail.com> - 2016-03-31 03:00 +0200
  Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Ming Lei <ming.lei@canonical.com> - 2016-03-30 03:40 +0200
    Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Shaohua Li <shli@fb.com> - 2016-03-30 04:30 +0200
      Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Ming Lei <ming.lei@canonical.com> - 2016-03-30 14:20 +0200
        Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Shaohua Li <shli@fb.com> - 2016-03-30 19:10 +0200
          Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Ming Lei <ming.lei@canonical.com> - 2016-03-31 02:50 +0200

csiph-web