lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Jan 2021 16:45:48 +0800 From: Ming Lei <ming.lei@...hat.com> To: Christoph Hellwig <hch@....de> Cc: Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, "Darrick J . Wong" <darrick.wong@...cle.com>, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [RFC PATCH] fs: block_dev: compute nr_vecs hint for improving writeback bvecs allocation On Tue, Jan 05, 2021 at 07:39:38PM +0100, Christoph Hellwig wrote: > At least for iomap I think this is the wrong approach. Between the > iomap and writeback_control we know the maximum size of the writeback > request and can just use that. I think writeback_control can tell us nothing about max pages in single bio: - wbc->nr_to_write controls how many pages to writeback, this pages usually don't belong to same bio. Also this number is often much bigger than BIO_MAX_PAGES. - wbc->range_start/range_end is similar too, which is often much more bigger than BIO_MAX_PAGES. Also page/blocks_in_page can be mapped to different extent too, which is only available when wpc->ops->map_blocks() is returned, which looks not different with mpage_writepages(), in which bio is allocated with BIO_MAX_PAGES vecs too. Or you mean we can use iomap->length for this purpose? But iomap->length still is still too big in case of xfs. -- Ming
Powered by blists - more mailing lists