All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Arthur Kiyanovski <akiyano@amazon.com>
Cc: "Harry Yoo (Meta)" <harry@kernel.org>,
	David Arinzon <darinzon@amazon.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Breno Leitao <leitao@debian.org>,
	<kernel-team@meta.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] net: ena: reuse the whole RX page on 64kB page kernels
Date: Fri, 13 Nov 2026 15:34:13 -0800	[thread overview]
Message-ID: <20261113153413.541945b6@kernel.org> (raw)
In-Reply-To: <179460571746.22458.2892088316099736810.b4-reply@b4>

On Fri, 13 Nov 2026 21:35:17 +0000 Arthur Kiyanovski wrote:
> On 2026-11-11 16:47:51-08:00, Jakub Kicinski wrote:
> > On Fri, 06 Nov 2026 03:17:11 +0000 Harry Yoo (Meta) wrote:
> >   
> > > This shows up when RX data stays in socket receive queues, as each
> > > queued skb keeps the whole 64kB page alive while at most 16kB of it
> > > holds data. On an EC2 t4g.large instance (64kB pages, 8GB memory) with
> > > 519MB left unread across 64 TCP sockets, RX pages pinned 2869MB of
> > > memory while the socket layer accounted only 687MB.  
> > 
> > I'm not sure you're actually fixing the problem you're describing?
> > You optimize the memory use but the (unused) tail of the buffer is
> > still not charged to any skb, is it? Or does it now fit perfectly?
> > 
> > Normally when the page can no longer be chunked up we should charge
> > the tail to whoever happened to use it last (see the page pool code
> > which does that).
> > 
> > Either way, you have to respin this on top of Breno's fix which
> > was applied earlier today.  
> 
> 
> Jakub,
> 
> If I understand correctly what you are saying, you are correct.
> skb->truesize is still not reported correctly.
> 
> The focus in this patch is different. It is about using the whole
> 64KB page instead of only the first 16KB.
> 
> Harry's own figures show most of it is recovered — 497MB pinned for
> 519MB unread, against 2869MB before — so the remaining gap is the
> final tail of each page, not the 48kB.
> 
> So I agree the commit message needs to be more precise.
> 
> The skb->truesize fix can come as a separate fix after this one.

You sent it twice? Some LLM automation gone wrong judging by the
m-dashes in your reply? :/

Making more efficient use of allocated pages is not a fix, and
will not be accepted to net or stable. Not accounting truesize 
correctly can be considered a fix. IOW the truesize accounting 
change has to come _first_. Then we can optimize the memory use 
w/ 64kB pages. They can both go to net-next, but the cannot both
go to net.

Hope spelling out practical implications of what I said earlier
makes it clear to everyone..

  reply	other threads:[~2026-11-13 23:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  3:17 [PATCH net-next] net: ena: reuse the whole RX page on 64kB page kernels Harry Yoo (Meta)
2026-11-06 10:09 ` Breno Leitao
2026-11-06 11:10   ` Harry Yoo
2026-11-12  0:47 ` Jakub Kicinski
2026-11-13 21:02   ` Arthur Kiyanovski
2026-11-13 21:35   ` Arthur Kiyanovski
2026-11-13 23:34     ` Jakub Kicinski [this message]
2026-11-13 21:10 ` Arthur Kiyanovski
2026-11-13 21:48 ` Arthur Kiyanovski

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=20261113153413.541945b6@kernel.org \
    --to=kuba@kernel.org \
    --cc=akiyano@amazon.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=darinzon@amazon.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=harry@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.