netdev - Re: [PATCH v2] mm: alloc_pages_bulk: remove assumption of populating only NULL elements

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <14170f7f-97d0-40b4-9b07-92e74168e030@huawei.com>
Date: Mon, 10 Mar 2025 20:31:49 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>, Yunsheng Lin
	<yunshenglin0825@...il.com>, Dave Chinner <david@...morbit.com>
CC: Yishai Hadas <yishaih@...dia.com>, Jason Gunthorpe <jgg@...pe.ca>, Shameer
 Kolothum <shameerali.kolothum.thodi@...wei.com>, Kevin Tian
	<kevin.tian@...el.com>, Alex Williamson <alex.williamson@...hat.com>, Chris
 Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba
	<dsterba@...e.com>, Gao Xiang <xiang@...nel.org>, Chao Yu <chao@...nel.org>,
	Yue Hu <zbestahu@...il.com>, Jeffle Xu <jefflexu@...ux.alibaba.com>, Sandeep
 Dhavale <dhavale@...gle.com>, Carlos Maiolino <cem@...nel.org>, "Darrick J.
 Wong" <djwong@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Jesper
 Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas
	<ilias.apalodimas@...aro.org>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Trond Myklebust
	<trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>, Chuck Lever
	<chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>, Neil Brown
	<neilb@...e.de>, Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo
	<Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, Luiz Capitulino
	<luizcap@...hat.com>, Mel Gorman <mgorman@...hsingularity.net>,
	<kvm@...r.kernel.org>, <virtualization@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <linux-btrfs@...r.kernel.org>,
	<linux-erofs@...ts.ozlabs.org>, <linux-xfs@...r.kernel.org>,
	<linux-mm@...ck.org>, <netdev@...r.kernel.org>, <linux-nfs@...r.kernel.org>
Subject: Re: [PATCH v2] mm: alloc_pages_bulk: remove assumption of populating
 only NULL elements

On 2025/3/10 8:32, Gao Xiang wrote:

...

>>
>> Also, it seems the fstests doesn't support erofs yet?
> 
> erofs is an read-only filesystem, and almost all xfstests
> cases is unsuitable for erofs since erofs needs to preset
> dataset in advance for runtime testing and only
> read-related interfaces are cared:
> 
> You could check erofs-specfic test cases here:
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/log/?h=experimental-tests
> 
> Also the stress test:
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=6fa861e282408f8df9ab1654b77b563444b17ea1

Thanks.

> 
> BTW, I don't like your new interface either, I don't know
> why you must insist on this work now that others are
> already nak this.  Why do you insist on it so much?

If the idea was not making any sense to me and it was nack'ed
with clearer reasoning and without any supporting of the idea,
I would have stopped working on it.

The background I started working at is something like below
in the commit log:
"As mentioned in [1], it seems odd to check NULL elements in
the middle of page bulk allocating, and it seems caller can
do a better job of bulk allocating pages into a whole array
sequentially without checking NULL elements first before
doing the page bulk allocation for most of existing users."

"Remove assumption of populating only NULL elements and treat
page_array as output parameter like kmem_cache_alloc_bulk().
Remove the above assumption also enable the caller to not
zero the array before calling the page bulk allocating API,
which has about 1~2 ns performance improvement for the test
case of time_bench_page_pool03_slow() for page_pool in a
x86 vm system, this reduces some performance impact of
fixing the DMA API misuse problem in [2], performance
improves from 87.886 ns to 86.429 ns."

1. https://lore.kernel.org/all/bd8c2f5c-464d-44ab-b607-390a87ea4cd5@huawei.com/
2. https://lore.kernel.org/all/20250212092552.1779679-1-linyunsheng@huawei.com/

There is no 'must' here, it is just me taking some of my
hoppy time and some of my work time trying to make the
alloc_pages_bulk API simpler and more efficient here, and I
also learnt a lot during that process.

Anyway, if there is still any hard nack after all the
discussion, it would be good to make it more explicit with
a clearer reasoning.