From: Jakub Kicinski <kuba@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, hawk@kernel.org,
ilias.apalodimas@linaro.org, davem@davemloft.net,
pabeni@redhat.com, bpf@vger.kernel.org,
lorenzo.bianconi@redhat.com, nbd@nbd.name
Subject: Re: issue with inflight pages from page_pool
Date: Mon, 17 Apr 2023 12:08:37 -0700 [thread overview]
Message-ID: <20230417120837.6f1e0ef6@kernel.org> (raw)
In-Reply-To: <ZD2TH4PsmSNayhfs@lore-desk>
On Mon, 17 Apr 2023 20:42:39 +0200 Lorenzo Bianconi wrote:
> > Is drgn available for your target? You could try to scan the pages on
> > the system and see if you can find what's still pointing to the page
> > pool (assuming they are indeed leaked and not returned to the page
> > allocator without releasing :()
>
> I will test it but since setting sysctl_skb_defer_max to 0 fixes the issue,
> I think the pages are still properly linked to the pool, they are just not
> returned to it. I proved it using the other patch I posted [0] where I can see
> the counter of returned pages incrementing from time to time (in a very long
> time slot..).
If it's that then I'm with Eric. There are many ways to keep the pages
in use, no point working around one of them and not the rest :(
> Unrelated to this issue, but debugging it I think a found a page_pool leak in
> skb_condense() [1] where we can reallocate the skb data using kmalloc for a
> page_pool recycled skb.
I don't see a problem having pp_recycle = 1 and head in slab is legal.
pp_recycle just means that *if* a page is from the page pool we own
the recycling reference. A page from slab will not be treated as a PP
page cause it doesn't have pp_magic set to the correct pattern.
next prev parent reply other threads:[~2023-04-17 19:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 17:53 issue with inflight pages from page_pool Lorenzo Bianconi
2023-04-17 18:08 ` Eric Dumazet
2023-04-17 18:17 ` Lorenzo Bianconi
2023-04-17 18:23 ` Jakub Kicinski
2023-04-17 18:42 ` Lorenzo Bianconi
2023-04-17 19:08 ` Jakub Kicinski [this message]
2023-04-17 21:31 ` Lorenzo Bianconi
2023-04-17 23:32 ` Jakub Kicinski
2023-04-18 7:36 ` Lorenzo Bianconi
2023-04-19 11:08 ` Jesper Dangaard Brouer
2023-04-19 12:09 ` Eric Dumazet
2023-04-19 14:02 ` Jesper Dangaard Brouer
2023-04-19 14:18 ` Eric Dumazet
2023-04-19 16:10 ` Jesper Dangaard Brouer
2023-04-19 14:21 ` Lorenzo Bianconi
2023-04-19 15:36 ` Jesper Dangaard Brouer
2023-04-19 16:40 ` Lorenzo Bianconi
2023-04-19 17:12 ` Jakub Kicinski
2023-04-17 18:24 ` Gerhard Engleder
2023-04-17 19:00 ` Lorenzo Bianconi
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=20230417120837.6f1e0ef6@kernel.org \
--to=kuba@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.