linux-kernel - Re: [PATCH] memcg: net: track network throttling due to memcg memory pressure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <pwy7qfx3afnadkjtemftqyrufhhexpw26srxfeilel5uhbywtt@cjvaean56txc>
Date: Thu, 16 Oct 2025 09:02:04 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Daniel Sedlak <daniel.sedlak@...77.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Muchun Song <muchun.song@...ux.dev>, Tejun Heo <tj@...nel.org>, 
	Eric Dumazet <edumazet@...gle.com>, Kuniyuki Iwashima <kuniyu@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Willem de Bruijn <willemb@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, "David S . Miller" <davem@...emloft.net>, 
	Matyas Hurtik <matyas.hurtik@...77.com>, Simon Horman <horms@...nel.org>, 
	Neal Cardwell <ncardwell@...gle.com>, Wei Wang <weibunny@...a.com>, netdev@...r.kernel.org, 
	linux-mm@...ck.org, cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Meta kernel team <kernel-team@...a.com>
Subject: Re: [PATCH] memcg: net: track network throttling due to memcg memory
 pressure

On Thu, Oct 16, 2025 at 12:42:19PM +0200, Daniel Sedlak wrote:
> On 10/16/25 3:31 AM, Shakeel Butt wrote:
> > The kernel can throttle network sockets if the memory cgroup associated
> > with the corresponding socket is under memory pressure. The throttling
> > actions include clamping the transmit window, failing to expand receive
> > or send buffers, aggressively prune out-of-order receive queue, FIN
> > deferred to a retransmitted packet and more. Let's add memcg metric to
> > indicate track such throttling actions.
> > 
> > At the moment memcg memory pressure is defined through vmpressure and in
> > future it may be defined using PSI or we may add more flexible way for
> > the users to define memory pressure, maybe through ebpf. However the
> > potential throttling actions will remain the same, so this newly
> > introduced metric will continue to track throttling actions irrespective
> > of how memcg memory pressure is defined.
> > 
> > Signed-off-by: Shakeel Butt <shakeel.butt@...ux.dev>
> 
> Reviewed-by: Daniel Sedlak <daniel.sedlak@...77.com>

Thanks.

> 
> I am curious how the future work will unfold. If you need help with future
> developments I can help you, we have hundreds of servers where this
> throttling is happening.

I think first thing I would like to know if this patch is a good start
for your use-case of observability and debugging. What else do you need
for sufficient support for your use-case? I imagine that would be
tracepoints to extract more information on the source of the throttling.
If you don't mind, can you take a stab at that? In the long run, we want
more flexible definition of memcg memory pressure. Let us know of any
requirements you have for that. Thanks again for continuosly pushing
this conversation.