[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <174121808436.33508.1242845473359255682@noble.neil.brown.name>
Date: Thu, 06 Mar 2025 10:41:24 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Yunsheng Lin" <linyunsheng@...wei.com>
Cc: "Qu Wenruo" <wqu@...e.com>, "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>, "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>,
"Dave Chinner" <david@...morbit.com>, 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 Wed, 05 Mar 2025, Yunsheng Lin wrote:
>
> For the existing btrfs and sunrpc case, I am agreed that there
> might be valid use cases too, we just need to discuss how to
> meet the requirements of different use cases using simpler, more
> unified and effective APIs.
We don't need "more unified".
If there are genuinely two different use cases with clearly different
needs - even if only slightly different - then it is acceptable to have
two different interfaces. Be sure to choose names which emphasise the
differences.
Thanks,
NeilBrown
Powered by blists - more mailing lists