From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jonathan Lemon <jonathan.lemon@gmail.com>
Cc: brouer@redhat.com, <netdev@vger.kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
kernel-team@fb.com, Jes Sorensen <jsorensen@fb.com>,
Saeed Mahameed <saeedm@mellanox.com>,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH 1/2 net-next] net: Don't return pfmemalloc pages to the page pool.
Date: Sat, 5 Jan 2019 16:46:09 +0100 [thread overview]
Message-ID: <20190105164609.3793fc02@redhat.com> (raw)
In-Reply-To: <20181220222133.1314092-1-jonathan.lemon@gmail.com>
On Thu, 20 Dec 2018 14:21:32 -0800
Jonathan Lemon <jonathan.lemon@gmail.com> wrote:
> Return pfmemalloc pages back to the page allocator, instead of holding them
> in the page pool.
>
> Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> ---
> net/core/page_pool.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index 43a932cb609b..364b893be66f 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -233,7 +233,7 @@ void __page_pool_put_page(struct page_pool *pool,
> *
> * refcnt == 1 means page_pool owns page, and can recycle it.
> */
> - if (likely(page_ref_count(page) == 1)) {
> + if (likely(page_ref_count(page) == 1 && !page_is_pfmemalloc(page))) {
I took at closer look at the page_pool issue recycling pages from
emergency reserve (pfmemalloc), and it actually cannot happen, because
page_pool does not use the __GFP_MEMALLOC gfp_t flag. Thus, page_pool
are not allowed to get pages from the emergency reserve in the first
place (unless ksoftirqd current->flags have PF_MEMALLOC, which I don't
think it have).
See: page_pool_dev_alloc_pages() compared to __dev_alloc_pages().
The doc for:
/* %__GFP_MEMALLOC allows access to all memory. This should only be used when
* the caller guarantees the allocation will allow more memory to be freed
* very shortly e.g. process exiting or swapping. Users either should
* be the MM or co-ordinating closely with the VM (e.g. swap over NFS).
*/
With that desc, I don't understand why we actually allow dev_alloc_pages()
to get emergency reserve (pfmemalloc) pages, as we store these in an
RX-ring queue (usual size 512-1024) that isn't used until N-packets
later... even if used as a signal to network stack, to free other
resources, this happens at a later point-in-time, not "very shortly".
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2019-01-05 15:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 22:21 [PATCH 1/2 net-next] net: Don't return pfmemalloc pages to the page pool Jonathan Lemon
2018-12-20 22:21 ` [PATCH 2/2 net-next] net: Use the __page_pool_return_page API Jonathan Lemon
2019-01-05 15:46 ` Jesper Dangaard Brouer [this message]
2019-01-07 19:10 ` [PATCH 1/2 net-next] net: Don't return pfmemalloc pages to the page pool Jonathan Lemon
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=20190105164609.3793fc02@redhat.com \
--to=brouer@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=jonathan.lemon@gmail.com \
--cc=jsorensen@fb.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.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.