lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 28 Nov 2018 06:44:00 -0700
From:   Jens Axboe <>
To:     Ming Lei <>
Cc:,,, Theodore Ts'o <>,
        Omar Sandoval <>,
        Sagi Grimberg <>,
        Dave Chinner <>,
        Kent Overstreet <>,
        Mike Snitzer <>,,
        Alexander Viro <>,, Shaohua Li <>,, David Sterba <>,,
        "Darrick J . Wong" <>,, Gao Xiang <>,
        Christoph Hellwig <>,,
        Coly Li <>,,
        Boaz Harrosh <>,
        Bob Peterson <>,
Subject: Re: [PATCH V12 00/20] block: support multi-page bvec

On 11/25/18 7:17 PM, Ming Lei wrote:
> Hi,
> This patchset brings multi-page bvec into block layer:
> 1) what is multi-page bvec?
> Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages
> which are physically contiguous instead of one single page used in linux
> kernel for long time.
> 2) why is multi-page bvec introduced?
> Kent proposed the idea[1] first. 
> As system's RAM becomes much bigger than before, and huge page, transparent
> huge page and memory compaction are widely used, it is a bit easy now
> to see physically contiguous pages from fs in I/O. On the other hand, from
> block layer's view, it isn't necessary to store intermediate pages into bvec,
> and it is enough to just store the physicallly contiguous 'segment' in each
> io vector.
> Also huge pages are being brought to filesystem and swap [2][6], we can
> do IO on a hugepage each time[3], which requires that one bio can transfer
> at least one huge page one time. Turns out it isn't flexiable to change
> BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well.
> As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured
> as much bigger, such as 512, which requires at least two 4K pages for holding
> the bvec table.

I'm pretty happy with this patchset at this point, looks like it just
needs a respin to address the last comments. My only concern is whether
it's a good idea to target this for 4.21, or if we should wait until
4.22. 4.21 has a fairly substantial amount of changes in terms of block
already, it's not the best timing for something of this magnitude too.

I'm going back and forth on those one a bit. Any concerns with
pushing this to 4.22?

Jens Axboe

Powered by blists - more mailing lists