[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230417112346.546dbe57@kernel.org>
Date: Mon, 17 Apr 2023 11:23:46 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Lorenzo Bianconi <lorenzo@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
hawk@...nel.org, ilias.apalodimas@...aro.org, davem@...emloft.net,
pabeni@...hat.com, bpf@...r.kernel.org,
lorenzo.bianconi@...hat.com, nbd@....name
Subject: Re: issue with inflight pages from page_pool
On Mon, 17 Apr 2023 20:17:45 +0200 Lorenzo Bianconi wrote:
> > I do not see why this would be different than having buffers sitting
> > in some tcp receive
> > (or out or order) queues for a few minutes ?
>
> The main issue in my tests (and even in mt76 I think) is the pages are not returned
> to the pool for a very long time (even hours) and doing so the pool is like in a
> 'limbo' state where it is not actually deallocated and page_pool_release_retry
> continues complaining about it. I think this is because we do not have more tcp
> traffic to deallocate them, but I am not so familiar with tcp codebase :)
I've seen the page leaks too in my recent testing but I just assumed
I fumbled the quick bnxt conversion to page pool. Could it be something
with page frags? It happened a lot if I used page frags, IIRC mt76 is
using page frags, too.
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 :()
Powered by blists - more mailing lists