Re: [PATCH v5] memcg: expose socket memory pressure in a cgroup
From: Roman Gushchin <roman.gushchin@linux.dev>
Date: 2025-10-15 20:17:52
Also in:
cgroups, linux-mm
Kuniyuki Iwashima [off-list ref] writes:
On Wed, Oct 15, 2025 at 11:39 AM Shakeel Butt [off-list ref] wrote:quoted
On Wed, Oct 15, 2025 at 11:21:17AM -0700, Kuniyuki Iwashima wrote:quoted
On Tue, Oct 14, 2025 at 1:33 PM Shakeel Butt [off-list ref] wrote:quoted
On Mon, Oct 13, 2025 at 04:30:53PM +0200, Daniel Sedlak wrote: [...]quoted
quoted
quoted
quoted
quoted
How about we track the actions taken by the callers of mem_cgroup_sk_under_memory_pressure()? Basically if network stack reduces the buffer size or whatever the other actions it may take when mem_cgroup_sk_under_memory_pressure() returns, tracking those actions is what I think is needed here, at least for the debugging use-case.I am not against it, but I feel that conveying those tracked actions (or how to represent them) to the user will be much harder. Are there already existing APIs to push this information to the user?I discussed with Wei Wang and she suggested we should start tracking the calls to tcp_adjust_rcv_ssthresh() first. So, something like the following. I would like feedback frm networking folks as well:I think we could simply put memcg_memory_event() in mem_cgroup_sk_under_memory_pressure() when it returns true. Other than tcp_adjust_rcv_ssthresh(), if tcp_under_memory_pressure() returns true, it indicates something bad will happen, failure to expand rcvbuf and sndbuf, need to prune out-of-order queue more aggressively, FIN deferred to a retransmitted packet. Also, we could cover mptcp and sctp too.I wanted to start simple and focus on one specific action but I am open to other actins as well. Do we want a generic network throttled metric or do we want different metric for different action? At the moment I think for memcg, a single metric would be sufficient and then we can have tracepoints for more fine grained debugging.I agree that a single metric would be enough if it can signal something bad is happening as a first step, then we can take further action with tracepoint, bpftrace, whatever.
+1 to a single metric