From: Yunsheng Lin <linyunsheng@huawei.com>
To: Chuck Lever <chuck.lever@oracle.com>,
Yishai Hadas <yishaih@nvidia.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
Kevin Tian <kevin.tian@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Gao Xiang <xiang@kernel.org>,
Chao Yu <chao@kernel.org>, Yue Hu <zbestahu@gmail.com>,
Jeffle Xu <jefflexu@linux.alibaba.com>,
Sandeep Dhavale <dhavale@google.com>,
Carlos Maiolino <cem@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Jeff Layton <jlayton@kernel.org>, Neil Brown <neilb@suse.de>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: Luiz Capitulino <luizcap@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>, <kvm@vger.kernel.org>,
<virtualization@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-btrfs@vger.kernel.org>, <linux-erofs@lists.ozlabs.org>,
<linux-xfs@vger.kernel.org>, <linux-mm@kvack.org>,
<netdev@vger.kernel.org>, <linux-nfs@vger.kernel.org>
Subject: Re: [RFC] mm: alloc_pages_bulk: remove assumption of populating only NULL elements
Date: Tue, 18 Feb 2025 17:16:00 +0800 [thread overview]
Message-ID: <cc6fc730-e5f4-485b-b0b6-ec70374b3ab1@huawei.com> (raw)
In-Reply-To: <abc3ae0b-620a-4e4a-8dd8-f8e7d3764b3a@oracle.com>
On 2025/2/17 22:20, Chuck Lever wrote:
> On 2/17/25 7:31 AM, Yunsheng Lin wrote:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating,
>
> I think I requested that check to be added to the bulk page allocator.
>
> When sending an RPC reply, NFSD might release pages in the middle of
It seems there is no usage of the page bulk allocation API in fs/nfsd/
or fs/nfs/, which specific fs the above 'NFSD' is referring to?
> the rq_pages array, marking each of those array entries with a NULL
> pointer. We want to ensure that the array is refilled completely in this
> case.
>
I did some researching, it seems you requested that in [1]?
It seems the 'holes are always at the start' for the case in that
discussion too, I am not sure if the case is referring to the caller
in net/sunrpc/svc_xprt.c? If yes, 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
as something below:
+++ b/net/sunrpc/svc_xprt.c
@@ -663,9 +663,10 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp)
pages = RPCSVC_MAXPAGES;
}
- for (filled = 0; filled < pages; filled = ret) {
- ret = alloc_pages_bulk(GFP_KERNEL, pages, rqstp->rq_pages);
- if (ret > filled)
+ for (filled = 0; filled < pages; filled += ret) {
+ ret = alloc_pages_bulk(GFP_KERNEL, pages - filled,
+ rqstp->rq_pages + filled);
+ if (ret)
/* Made progress, don't sleep yet */
continue;
@@ -674,7 +675,7 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp)
set_current_state(TASK_RUNNING);
return false;
}
- trace_svc_alloc_arg_err(pages, ret);
+ trace_svc_alloc_arg_err(pages, filled);
memalloc_retry_wait(GFP_KERNEL);
}
rqstp->rq_page_end = &rqstp->rq_pages[pages];
1. https://lkml.iu.edu/hypermail/linux/kernel/2103.2/09060.html
WARNING: multiple messages have this Message-ID (diff)
From: Yunsheng Lin via Linux-erofs <linux-erofs@lists.ozlabs.org>
To: Chuck Lever <chuck.lever@oracle.com>,
Yishai Hadas <yishaih@nvidia.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
Kevin Tian <kevin.tian@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Gao Xiang <xiang@kernel.org>,
Chao Yu <chao@kernel.org>, Yue Hu <zbestahu@gmail.com>,
Jeffle Xu <jefflexu@linux.alibaba.com>,
Sandeep Dhavale <dhavale@google.com>,
Carlos Maiolino <cem@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Jeff Layton <jlayton@kernel.org>, Neil Brown <neilb@suse.de>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, kvm@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux.dev, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, netdev@vger.kernel.org,
Mel Gorman <mgorman@techsingularity.net>,
linux-btrfs@vger.kernel.org, Luiz Capitulino <luizcap@redhat.com>
Subject: Re: [RFC] mm: alloc_pages_bulk: remove assumption of populating only NULL elements
Date: Tue, 18 Feb 2025 17:16:00 +0800 [thread overview]
Message-ID: <cc6fc730-e5f4-485b-b0b6-ec70374b3ab1@huawei.com> (raw)
In-Reply-To: <abc3ae0b-620a-4e4a-8dd8-f8e7d3764b3a@oracle.com>
On 2025/2/17 22:20, Chuck Lever wrote:
> On 2/17/25 7:31 AM, Yunsheng Lin wrote:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating,
>
> I think I requested that check to be added to the bulk page allocator.
>
> When sending an RPC reply, NFSD might release pages in the middle of
It seems there is no usage of the page bulk allocation API in fs/nfsd/
or fs/nfs/, which specific fs the above 'NFSD' is referring to?
> the rq_pages array, marking each of those array entries with a NULL
> pointer. We want to ensure that the array is refilled completely in this
> case.
>
I did some researching, it seems you requested that in [1]?
It seems the 'holes are always at the start' for the case in that
discussion too, I am not sure if the case is referring to the caller
in net/sunrpc/svc_xprt.c? If yes, 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
as something below:
+++ b/net/sunrpc/svc_xprt.c
@@ -663,9 +663,10 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp)
pages = RPCSVC_MAXPAGES;
}
- for (filled = 0; filled < pages; filled = ret) {
- ret = alloc_pages_bulk(GFP_KERNEL, pages, rqstp->rq_pages);
- if (ret > filled)
+ for (filled = 0; filled < pages; filled += ret) {
+ ret = alloc_pages_bulk(GFP_KERNEL, pages - filled,
+ rqstp->rq_pages + filled);
+ if (ret)
/* Made progress, don't sleep yet */
continue;
@@ -674,7 +675,7 @@ static bool svc_alloc_arg(struct svc_rqst *rqstp)
set_current_state(TASK_RUNNING);
return false;
}
- trace_svc_alloc_arg_err(pages, ret);
+ trace_svc_alloc_arg_err(pages, filled);
memalloc_retry_wait(GFP_KERNEL);
}
rqstp->rq_page_end = &rqstp->rq_pages[pages];
1. https://lkml.iu.edu/hypermail/linux/kernel/2103.2/09060.html
next prev parent reply other threads:[~2025-02-18 9:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 12:31 [RFC] mm: alloc_pages_bulk: remove assumption of populating only NULL elements Yunsheng Lin
2025-02-17 12:31 ` Yunsheng Lin via Linux-erofs
2025-02-17 14:02 ` Jeff Layton
2025-02-17 14:02 ` Jeff Layton via Linux-erofs
2025-02-17 14:20 ` Chuck Lever
2025-02-17 14:20 ` Chuck Lever via Linux-erofs
2025-02-18 9:16 ` Yunsheng Lin [this message]
2025-02-18 9:16 ` Yunsheng Lin via Linux-erofs
2025-02-18 14:17 ` Chuck Lever
2025-02-18 14:17 ` Chuck Lever via Linux-erofs
2025-02-21 9:34 ` Yunsheng Lin
2025-02-21 9:34 ` Yunsheng Lin via Linux-erofs
2025-02-17 21:31 ` Dave Chinner
2025-02-17 21:31 ` Dave Chinner via Linux-erofs
2025-02-18 9:21 ` Yunsheng Lin
2025-02-18 9:21 ` Yunsheng Lin via Linux-erofs
2025-02-18 21:14 ` Dave Chinner
2025-02-18 21:14 ` Dave Chinner via Linux-erofs
2025-02-19 11:20 ` Yunsheng Lin
2025-02-19 11:20 ` Yunsheng Lin via Linux-erofs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cc6fc730-e5f4-485b-b0b6-ec70374b3ab1@huawei.com \
--to=linyunsheng@huawei.com \
--cc=Dai.Ngo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=anna@kernel.org \
--cc=cem@kernel.org \
--cc=chao@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=clm@fb.com \
--cc=davem@davemloft.net \
--cc=dhavale@google.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jefflexu@linux.alibaba.com \
--cc=jgg@ziepe.ca \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kevin.tian@intel.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=luizcap@redhat.com \
--cc=mgorman@techsingularity.net \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=xiang@kernel.org \
--cc=yishaih@nvidia.com \
--cc=zbestahu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.