Some protocols (e.g., TCP, UDP) have their own memory accounting for
socket buffers and charge memory to global per-protocol counters such
as /proc/net/ipv4/tcp_mem.
When running under a non-root cgroup, this memory is also charged to
the memcg as sock in memory.stat.
Sockets of such protocols are still subject to the global limits,
thus affected by a noisy neighbour outside cgroup.
This makes it difficult to accurately estimate and configure appropriate
global limits.
If all workloads were guaranteed to be controlled under memcg, the issue
can be worked around by setting tcp_mem[0~2] to UINT_MAX.
However, this assumption does not always hold, and processes that belong
to the root cgroup or opt out of memcg can consume memory up to the global
limit, which is problematic.
This series decouples memcg from the global memory accounting if its
memory.max is not "max". This simplifies the memcg configuration while
keeping the global limits within a reasonable range, which is only 10% of
the physical memory by default.
Overview of the series:
patch 1 is a bug fix for MPTCP
patch 2 ~ 9 move sk->sk_memcg accesses to a single place
patch 10 moves sk_memcg under CONFIG_MEMCG
patch 11 stores a flag in the lowest bit of sk->sk_memcg
patch 12 decouples memcg from sk_prot->memory_allocated based on the flag
Changes:
v3:
* Patch 12
* Fix build failrue for kTLS (include <net/proto_memory.h>)
v2: https://lore.kernel.org/netdev/20250811173116.2829786-1-kuniyu@google.com/
* Remove per-memcg knob
* Patch 11
* Set flag on sk_memcg based on memory.max
* Patch 12
* Add sk_should_enter_memory_pressure() and cover
tcp_enter_memory_pressure() calls
* Update examples in changelog
v1: https://lore.kernel.org/netdev/20250721203624.3807041-1-kuniyu@google.com/
Kuniyuki Iwashima (12):
mptcp: Fix up subflow's memcg when CONFIG_SOCK_CGROUP_DATA=n.
mptcp: Use tcp_under_memory_pressure() in mptcp_epollin_ready().
tcp: Simplify error path in inet_csk_accept().
net: Call trace_sock_exceed_buf_limit() for memcg failure with
SK_MEM_RECV.
net: Clean up __sk_mem_raise_allocated().
net-memcg: Introduce mem_cgroup_from_sk().
net-memcg: Introduce mem_cgroup_sk_enabled().
net-memcg: Pass struct sock to mem_cgroup_sk_(un)?charge().
net-memcg: Pass struct sock to mem_cgroup_sk_under_memory_pressure().
net: Define sk_memcg under CONFIG_MEMCG.
net-memcg: Store MEMCG_SOCK_ISOLATED in sk->sk_memcg.
net-memcg: Decouple controlled memcg from global protocol memory
accounting.
include/linux/memcontrol.h | 45 +++++++++-------
include/net/proto_memory.h | 15 ++++--
include/net/sock.h | 67 +++++++++++++++++++++++
include/net/tcp.h | 10 ++--
mm/memcontrol.c | 48 +++++++++++++----
net/core/sock.c | 94 +++++++++++++++++++++------------
net/ipv4/inet_connection_sock.c | 35 +++++++-----
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_output.c | 13 +++--
net/mptcp/protocol.c | 4 +-
net/mptcp/protocol.h | 4 +-
net/mptcp/subflow.c | 11 ++--
net/tls/tls_device.c | 4 +-
13 files changed, 254 insertions(+), 99 deletions(-)
--
2.51.0.rc0.205.g4a044479a3-goog
When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets
sk->sk_memcg based on the current task.
MPTCP subflow socket creation is triggered from userspace or
an in-kernel worker.
In the latter case, sk->sk_memcg is not what we want. So, we fix
it up from the parent socket's sk->sk_memcg in mptcp_attach_cgroup().
Although the code is placed under #ifdef CONFIG_MEMCG, it is buried
under #ifdef CONFIG_SOCK_CGROUP_DATA.
The two configs are orthogonal. If CONFIG_MEMCG is enabled without
CONFIG_SOCK_CGROUP_DATA, the subflow's memory usage is not charged
correctly.
Let's move the code out of the wrong ifdef guard.
Note that sk->sk_memcg is freed in sk_prot_free() and the parent
sk holds the refcnt of memcg->css here, so we don't need to use
css_tryget().
Fixes: 3764b0c5651e3 ("mptcp: attach subflow socket to parent cgroup")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
include/linux/memcontrol.h | 6 ++++++
mm/memcontrol.c | 10 ++++++++++
net/mptcp/subflow.c | 11 +++--------
3 files changed, 19 insertions(+), 8 deletions(-)
@@ -1717,19 +1717,14 @@ static void mptcp_attach_cgroup(struct sock *parent, struct sock *child)/* only the additional subflows created by kworkers have to be modified */if(cgroup_id(sock_cgroup_ptr(parent_skcd))!=cgroup_id(sock_cgroup_ptr(child_skcd))){-#ifdef CONFIG_MEMCG-structmem_cgroup*memcg=parent->sk_memcg;--mem_cgroup_sk_free(child);-if(memcg&&css_tryget(&memcg->css))-child->sk_memcg=memcg;-#endif /* CONFIG_MEMCG */-cgroup_sk_free(child_skcd);*child_skcd=*parent_skcd;cgroup_sk_clone(child_skcd);}#endif /* CONFIG_SOCK_CGROUP_DATA */++if(mem_cgroup_sockets_enabled&&parent->sk_memcg)+mem_cgroup_sk_inherit(parent,child);}staticvoidmptcp_subflow_ops_override(structsock*ssk)
Some conditions used in mptcp_epollin_ready() are the same as
tcp_under_memory_pressure().
We will modify tcp_under_memory_pressure() in the later patch.
Let's use tcp_under_memory_pressure() instead.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
net/mptcp/protocol.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
When an error occurs in inet_csk_accept(), what we should do is
only call release_sock() and set the errno to arg->err.
But the path jumps to another label, which introduces unnecessary
initialisation and tests for newsk.
Let's simplify the error path and remove the redundant NULL
checks for newsk.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/inet_connection_sock.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
Initially, trace_sock_exceed_buf_limit() was invoked when
__sk_mem_raise_allocated() failed due to the memcg limit or the
global limit.
However, commit d6f19938eb031 ("net: expose sk wmem in
sock_exceed_buf_limit tracepoint") somehow suppressed the event
only when memcg failed to charge for SK_MEM_RECV, although the
memcg failure for SK_MEM_SEND still triggers the event.
Let's restore the event for SK_MEM_RECV.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
net/core/sock.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
@@ -3354,8 +3354,7 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)}}-if(kind==SK_MEM_SEND||(kind==SK_MEM_RECV&&charged))-trace_sock_exceed_buf_limit(sk,prot,allocated,kind);+trace_sock_exceed_buf_limit(sk,prot,allocated,kind);sk_memory_allocated_sub(sk,amt);
In __sk_mem_raise_allocated(), charged is initialised as true due
to the weird condition removed in the previous patch.
It makes the variable unreliable by itself, so we have to check
another variable, memcg, in advance.
Also, we will factorise the common check below for memcg later.
if (mem_cgroup_sockets_enabled && sk->sk_memcg)
As a prep, let's initialise charged as false and memcg as NULL.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
net/core/sock.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
@@ -3358,7 +3359,7 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)sk_memory_allocated_sub(sk,amt);-if(memcg&&charged)+if(charged)mem_cgroup_uncharge_skmem(memcg,amt);return0;
We will store a flag in the lowest bit of sk->sk_memcg.
Then, directly dereferencing sk->sk_memcg will be illegal, and we
do not want to allow touching the raw sk->sk_memcg in many places.
Let's introduce mem_cgroup_from_sk().
Other places accessing the raw sk->sk_memcg will be converted later.
Note that we cannot define the helper as an inline function in
memcontrol.h as we cannot access any fields of struct sock there
due to circular dependency, so it is placed in sock.h.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 12 ++++++++++++
mm/memcontrol.c | 14 +++++++++-----
net/ipv4/inet_connection_sock.c | 2 +-
3 files changed, 22 insertions(+), 6 deletions(-)
@@ -718,7 +718,7 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg)lock_sock(newsk);mem_cgroup_sk_alloc(newsk);-if(newsk->sk_memcg){+if(mem_cgroup_from_sk(newsk)){/* The socket has not been accepted yet, no need*tolookatnewsk->sk_wmem_queued.*/
The socket memcg feature is enabled by a static key and
only works for non-root cgroup.
We check both conditions in many places.
Let's factorise it as a helper function.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
include/net/proto_memory.h | 2 +-
include/net/sock.h | 10 ++++++++++
include/net/tcp.h | 2 +-
net/core/sock.c | 6 +++---
net/ipv4/tcp_output.c | 2 +-
net/mptcp/subflow.c | 2 +-
6 files changed, 17 insertions(+), 7 deletions(-)
@@ -275,7 +275,7 @@ extern unsigned long tcp_memory_pressure;/* optimized version of sk_under_memory_pressure() for TCP sockets */staticinlinebooltcp_under_memory_pressure(conststructsock*sk){-if(mem_cgroup_sockets_enabled&&sk->sk_memcg&&+if(mem_cgroup_sk_enabled(sk)&&mem_cgroup_under_socket_pressure(sk->sk_memcg))returntrue;
@@ -1032,7 +1032,7 @@ static int sock_reserve_memory(struct sock *sk, int bytes)boolcharged;intpages;-if(!mem_cgroup_sockets_enabled||!sk->sk_memcg||!sk_has_account(sk))+if(!mem_cgroup_sk_enabled(sk)||!sk_has_account(sk))return-EOPNOTSUPP;if(!bytes)
@@ -3271,7 +3271,7 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)sk_memory_allocated_add(sk,amt);allocated=sk_memory_allocated(sk);-if(mem_cgroup_sockets_enabled&&sk->sk_memcg){+if(mem_cgroup_sk_enabled(sk)){memcg=sk->sk_memcg;charged=mem_cgroup_charge_skmem(memcg,amt,gfp_memcg_charge());if(!charged)
@@ -3398,7 +3398,7 @@ void __sk_mem_reduce_allocated(struct sock *sk, int amount){sk_memory_allocated_sub(sk,amount);-if(mem_cgroup_sockets_enabled&&sk->sk_memcg)+if(mem_cgroup_sk_enabled(sk))mem_cgroup_uncharge_skmem(sk->sk_memcg,amount);if(sk_under_global_memory_pressure(sk)&&
We will store a flag in the lowest bit of sk->sk_memcg.
Then, we cannot pass the raw pointer to mem_cgroup_charge_skmem()
and mem_cgroup_uncharge_skmem().
Let's pass struct sock to the functions.
While at it, they are renamed to match other functions starting
with mem_cgroup_sk_.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
include/linux/memcontrol.h | 29 ++++++++++++++++++++++++-----
mm/memcontrol.c | 18 +++++++++++-------
net/core/sock.c | 24 +++++++++++-------------
net/ipv4/inet_connection_sock.c | 2 +-
net/ipv4/tcp_output.c | 3 +--
5 files changed, 48 insertions(+), 28 deletions(-)
@@ -1041,8 +1041,8 @@ static int sock_reserve_memory(struct sock *sk, int bytes)pages=sk_mem_pages(bytes);/* pre-charge to memcg */-charged=mem_cgroup_charge_skmem(sk->sk_memcg,pages,-GFP_KERNEL|__GFP_RETRY_MAYFAIL);+charged=mem_cgroup_sk_charge(sk,pages,+GFP_KERNEL|__GFP_RETRY_MAYFAIL);if(!charged)return-ENOMEM;
@@ -1054,7 +1054,7 @@ static int sock_reserve_memory(struct sock *sk, int bytes)*/if(allocated>sk_prot_mem_limits(sk,1)){sk_memory_allocated_sub(sk,pages);-mem_cgroup_uncharge_skmem(sk->sk_memcg,pages);+mem_cgroup_sk_uncharge(sk,pages);return-ENOMEM;}sk_forward_alloc_add(sk,pages<<PAGE_SHIFT);
@@ -3347,10 +3346,9 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)*/if(sk->sk_wmem_queued+size>=sk->sk_sndbuf){/* Force charge with __GFP_NOFAIL */-if(memcg&&!charged){-mem_cgroup_charge_skmem(memcg,amt,-gfp_memcg_charge()|__GFP_NOFAIL);-}+if(memcg_enabled&&!charged)+mem_cgroup_sk_charge(sk,amt,+gfp_memcg_charge()|__GFP_NOFAIL);return1;}}
@@ -3360,7 +3358,7 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)sk_memory_allocated_sub(sk,amt);if(charged)-mem_cgroup_uncharge_skmem(memcg,amt);+mem_cgroup_sk_uncharge(sk,amt);return0;}
@@ -3399,7 +3397,7 @@ void __sk_mem_reduce_allocated(struct sock *sk, int amount)sk_memory_allocated_sub(sk,amount);if(mem_cgroup_sk_enabled(sk))-mem_cgroup_uncharge_skmem(sk->sk_memcg,amount);+mem_cgroup_sk_uncharge(sk,amount);if(sk_under_global_memory_pressure(sk)&&(sk_memory_allocated(sk)<sk_prot_mem_limits(sk,0)))
@@ -3579,8 +3579,7 @@ void sk_forced_mem_schedule(struct sock *sk, int size)sk_memory_allocated_add(sk,amt);if(mem_cgroup_sk_enabled(sk))-mem_cgroup_charge_skmem(sk->sk_memcg,amt,-gfp_memcg_charge()|__GFP_NOFAIL);+mem_cgroup_sk_charge(sk,amt,gfp_memcg_charge()|__GFP_NOFAIL);}/* Send a FIN. The caller locks the socket for us.
We will store a flag in the lowest bit of sk->sk_memcg.
Then, we cannot pass the raw pointer to mem_cgroup_under_socket_pressure().
Let's pass struct sock to it and rename the function to match other
functions starting with mem_cgroup_sk_.
Note that the helper is moved to sock.h to use mem_cgroup_from_sk().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
include/linux/memcontrol.h | 18 ------------------
include/net/proto_memory.h | 2 +-
include/net/sock.h | 22 ++++++++++++++++++++++
include/net/tcp.h | 2 +-
4 files changed, 24 insertions(+), 20 deletions(-)
Except for sk_clone_lock(), all accesses to sk->sk_memcg
is done under CONFIG_MEMCG.
As a bonus, let's define sk->sk_memcg under CONFIG_MEMCG.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 2 ++
net/core/sock.c | 4 ++++
2 files changed, 6 insertions(+)
We will decouple sockets from the global protocol memory accounting
if the cgroup's memory.max is not "max" (PAGE_COUNTER_MAX).
memory.max can change at any time, so we must snapshot the state
for each socket to ensure consistency.
Given sk->sk_memcg can be accessed in the fast path, it would
be preferable to place the flag field in the same cache line as
sk->sk_memcg.
However, struct sock does not have such a 1-byte hole.
Let's store the flag in the lowest bit of sk->sk_memcg and add
a helper to check the bit.
In the next patch, if mem_cgroup_sk_isolated() returns true,
the socket will not be charged to sk->sk_prot->memory_allocated.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
v2:
* Set MEMCG_SOCK_ISOLATED based on memory.max instead of
a dedicated knob
---
include/net/sock.h | 23 ++++++++++++++++++++++-
mm/memcontrol.c | 14 ++++++++++++--
2 files changed, 34 insertions(+), 3 deletions(-)
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
When running under a non-root cgroup, this memory is also charged to the
memcg as "sock" in memory.stat.
Even when a memcg controls memory usage, sockets of such protocols are
still subject to global limits (e.g., /proc/sys/net/ipv4/tcp_mem).
This makes it difficult to accurately estimate and configure appropriate
global limits, especially in multi-tenant environments.
If all workloads were guaranteed to be controlled under memcg, the issue
could be worked around by setting tcp_mem[0~2] to UINT_MAX.
In reality, this assumption does not always hold, and processes that
belong to the root cgroup or opt out of memcg can consume memory up to
the global limit, becoming a noisy neighbour.
Let's decouple memcg from the global per-protocol memory accounting if
it has a finite memory.max (!= "max").
We still keep charging memory to memcg and protocol duplicately if
memcg has "max" in memory.max because TCP allows only 10% of physical
memory by default.
This simplifies memcg configuration while keeping the global limits
within a reasonable range.
If mem_cgroup_sk_isolated(sk) returns true, the per-protocol memory
accounting is skipped.
In inet_csk_accept(), we need to reclaim counts that are already charged
for child sockets because we do not allocate sk->sk_memcg until accept().
Note that trace_sock_exceed_buf_limit() will always show 0 as accounted
for the isolated sockets, but this can be obtained via memory.stat.
Tested with a script that creates local socket pairs and send()s a
bunch of data without recv()ing.
Setup:
# mkdir /sys/fs/cgroup/test
# echo $$ >> /sys/fs/cgroup/test/cgroup.procs
# sysctl -q net.ipv4.tcp_mem="1000 1000 1000"
Without setting memory.max:
# prlimit -n=524288:524288 bash -c "python3 pressure.py" &
# cat /sys/fs/cgroup/test/memory.stat | grep sock
sock 22642688
# ss -tn | head -n 5
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 2000 0 127.0.0.1:34479 127.0.0.1:53188
ESTAB 2000 0 127.0.0.1:34479 127.0.0.1:49972
ESTAB 2000 0 127.0.0.1:34479 127.0.0.1:53868
ESTAB 2000 0 127.0.0.1:34479 127.0.0.1:53554
# nstat | grep Pressure || echo no pressure
TcpExtTCPMemoryPressures 1 0.0
With memory.max:
# echo $((64 * 1024 ** 3)) > /sys/fs/cgroup/test/memory.max
# prlimit -n=524288:524288 bash -c "python3 pressure.py" &
# cat /sys/fs/cgroup/test/memory.stat | grep sock
sock 2757468160
# ss -tn | head -n 5
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 111000 0 127.0.0.1:36019 127.0.0.1:49026
ESTAB 110000 0 127.0.0.1:36019 127.0.0.1:45630
ESTAB 110000 0 127.0.0.1:36019 127.0.0.1:44870
ESTAB 111000 0 127.0.0.1:36019 127.0.0.1:45274
# nstat | grep Pressure || echo no pressure
no pressure
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
v3:
* Fix build failure for kTLS
v2:
* Add sk_should_enter_memory_pressure() for
tcp_enter_memory_pressure() calls not in core
* Update example in changelog
---
include/net/proto_memory.h | 15 ++++++--
include/net/tcp.h | 10 ++++--
net/core/sock.c | 64 ++++++++++++++++++++++-----------
net/ipv4/inet_connection_sock.c | 18 ++++++++--
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_output.c | 10 ++++--
net/mptcp/protocol.c | 4 ++-
net/tls/tls_device.c | 4 ++-
8 files changed, 94 insertions(+), 34 deletions(-)
@@ -275,9 +275,13 @@ extern unsigned long tcp_memory_pressure;/* optimized version of sk_under_memory_pressure() for TCP sockets */staticinlinebooltcp_under_memory_pressure(conststructsock*sk){-if(mem_cgroup_sk_enabled(sk)&&-mem_cgroup_sk_under_memory_pressure(sk))-returntrue;+if(mem_cgroup_sk_enabled(sk)){+if(mem_cgroup_sk_under_memory_pressure(sk))+returntrue;++if(mem_cgroup_sk_isolated(sk))+returnfalse;+}returnREAD_ONCE(tcp_memory_pressure);}
@@ -1046,17 +1046,21 @@ static int sock_reserve_memory(struct sock *sk, int bytes)if(!charged)return-ENOMEM;-/* pre-charge to forward_alloc */-sk_memory_allocated_add(sk,pages);-allocated=sk_memory_allocated(sk);-/* If the system goes into memory pressure with this-*precharge,giveupandreturnerror.-*/-if(allocated>sk_prot_mem_limits(sk,1)){-sk_memory_allocated_sub(sk,pages);-mem_cgroup_sk_uncharge(sk,pages);-return-ENOMEM;+if(!mem_cgroup_sk_isolated(sk)){+/* pre-charge to forward_alloc */+sk_memory_allocated_add(sk,pages);+allocated=sk_memory_allocated(sk);++/* If the system goes into memory pressure with this+*precharge,giveupandreturnerror.+*/+if(allocated>sk_prot_mem_limits(sk,1)){+sk_memory_allocated_sub(sk,pages);+mem_cgroup_sk_uncharge(sk,pages);+return-ENOMEM;+}}+sk_forward_alloc_add(sk,pages<<PAGE_SHIFT);WRITE_ONCE(sk->sk_reserved_mem,
@@ -3267,18 +3274,30 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind){boolmemcg_enabled=false,charged=false;structproto*prot=sk->sk_prot;-longallocated;--sk_memory_allocated_add(sk,amt);-allocated=sk_memory_allocated(sk);+longallocated=0;if(mem_cgroup_sk_enabled(sk)){+boolisolated=mem_cgroup_sk_isolated(sk);+memcg_enabled=true;charged=mem_cgroup_sk_charge(sk,amt,gfp_memcg_charge());-if(!charged)++if(isolated&&charged)+return1;++if(!charged){+if(!isolated){+sk_memory_allocated_add(sk,amt);+allocated=sk_memory_allocated(sk);+}+gotosuppress_allocation;+}}+sk_memory_allocated_add(sk,amt);+allocated=sk_memory_allocated(sk);+/* Under limit. */if(allocated<=sk_prot_mem_limits(sk,0)){sk_leave_memory_pressure(sk);
@@ -3357,7 +3376,8 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)trace_sock_exceed_buf_limit(sk,prot,allocated,kind);-sk_memory_allocated_sub(sk,amt);+if(allocated)+sk_memory_allocated_sub(sk,amt);if(charged)mem_cgroup_sk_uncharge(sk,amt);
@@ -22,6 +22,7 @@#include<net/tcp.h>#include<net/sock_reuseport.h>#include<net/addrconf.h>+#include<net/proto_memory.h>#if IS_ENABLED(CONFIG_IPV6)/* match_sk*_wildcard == true: IPV6_ADDR_ANY equals to any IPv6 addresses
@@ -710,7 +711,6 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg)if(mem_cgroup_sockets_enabled){gfp_tgfp=GFP_KERNEL|__GFP_NOFAIL;-intamt=0;/* atomically get the memory usage, set and charge the*newsk->sk_memcg.
@@ -719,15 +719,27 @@ struct sock *inet_csk_accept(struct sock *sk, struct proto_accept_arg *arg)mem_cgroup_sk_alloc(newsk);if(mem_cgroup_from_sk(newsk)){+intamt;+/* The socket has not been accepted yet, no need*tolookatnewsk->sk_wmem_queued.*/amt=sk_mem_pages(newsk->sk_forward_alloc+atomic_read(&newsk->sk_rmem_alloc));+if(amt){+/* This amt is already charged globally to+*sk_prot->memory_allocatedduetolackof+*sk_memcguntilaccept(),thusweneedto+*reclaimithereifnewskisisolated.+*/+if(mem_cgroup_sk_isolated(newsk))+sk_memory_allocated_sub(newsk,amt);++mem_cgroup_sk_charge(newsk,amt,gfp);+}+}-if(amt)-mem_cgroup_sk_charge(newsk,amt,gfp);kmem_cache_charge(newsk,gfp);release_sock(newsk);
@@ -3574,12 +3574,18 @@ void sk_forced_mem_schedule(struct sock *sk, int size)delta=size-sk->sk_forward_alloc;if(delta<=0)return;+amt=sk_mem_pages(delta);sk_forward_alloc_add(sk,amt<<PAGE_SHIFT);-sk_memory_allocated_add(sk,amt);-if(mem_cgroup_sk_enabled(sk))+if(mem_cgroup_sk_enabled(sk)){mem_cgroup_sk_charge(sk,amt,gfp_memcg_charge()|__GFP_NOFAIL);++if(mem_cgroup_sk_isolated(sk))+return;+}++sk_memory_allocated_add(sk,amt);}/* Send a FIN. The caller locks the socket for us.
On Tue, Aug 12, 2025 at 05:58:30PM +0000, Kuniyuki Iwashima wrote:
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
When running under a non-root cgroup, this memory is also charged to the
memcg as "sock" in memory.stat.
Even when a memcg controls memory usage, sockets of such protocols are
still subject to global limits (e.g., /proc/sys/net/ipv4/tcp_mem).
This makes it difficult to accurately estimate and configure appropriate
global limits, especially in multi-tenant environments.
If all workloads were guaranteed to be controlled under memcg, the issue
could be worked around by setting tcp_mem[0~2] to UINT_MAX.
In reality, this assumption does not always hold, and processes that
belong to the root cgroup or opt out of memcg can consume memory up to
the global limit, becoming a noisy neighbour.
Processes running in root memcg (I am not sure what does 'opt out of
memcg means') means admin has intentionally allowed scenarios where
noisy neighbour situation can happen, so I am not really following your
argument here.
Let's decouple memcg from the global per-protocol memory accounting if
it has a finite memory.max (!= "max").
Why decouple only for some? (Also if you really want to check memcg
limits, you need to check limits for all ancestors and not just the
given memcg).
Why not start with just two global options (maybe start with boot
parameter)?
Option 1: Existing behavior where memcg and global TCP accounting are
coupled.
Option 2: Completely decouple memcg and global TCP accounting i.e. use
mem_cgroup_sockets_enabled to either do global TCP accounting or memcg
accounting.
Keep the option 1 default.
I assume you want third option where a mix of these options can happen
i.e. some sockets are only accounted to a memcg and some are accounted
to both memcg and global TCP. I would recommend to make that a followup
patch series. Keep this series simple and non-controversial.
Hi Kuniyuki,
On 12/08/2025 19:58, Kuniyuki Iwashima wrote:
When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets
sk->sk_memcg based on the current task.
MPTCP subflow socket creation is triggered from userspace or
an in-kernel worker.
In the latter case, sk->sk_memcg is not what we want. So, we fix
it up from the parent socket's sk->sk_memcg in mptcp_attach_cgroup().
Although the code is placed under #ifdef CONFIG_MEMCG, it is buried
under #ifdef CONFIG_SOCK_CGROUP_DATA.
The two configs are orthogonal. If CONFIG_MEMCG is enabled without
CONFIG_SOCK_CGROUP_DATA, the subflow's memory usage is not charged
correctly.
Let's move the code out of the wrong ifdef guard.
Note that sk->sk_memcg is freed in sk_prot_free() and the parent
sk holds the refcnt of memcg->css here, so we don't need to use
css_tryget().
Thank you for the patch!
Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
Hi Kuniyuki,
On 12/08/2025 19:58, Kuniyuki Iwashima wrote:
Some conditions used in mptcp_epollin_ready() are the same as
tcp_under_memory_pressure().
We will modify tcp_under_memory_pressure() in the later patch.
Let's use tcp_under_memory_pressure() instead.
Good idea, thanks!
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
From: Johannes Weiner <hannes@cmpxchg.org> Date: 2025-08-13 13:00:20
On Tue, Aug 12, 2025 at 05:58:30PM +0000, Kuniyuki Iwashima wrote:
If all workloads were guaranteed to be controlled under memcg, the issue
could be worked around by setting tcp_mem[0~2] to UINT_MAX.
In reality, this assumption does not always hold, and processes that
belong to the root cgroup or opt out of memcg can consume memory up to
the global limit, becoming a noisy neighbour.
As per the last thread, this is not a supported usecase. Opting out of
memcg coverage for individual cgroups is a self-inflicted problem and
misconfiguration. There is *no* memory isolation *at all* on such
containers. Maybe their socket buffers is the only thing that happens
to matter to *you*, but this is in no way a generic, universal,
upstreamable solution. Knob or auto-detection is not the issue.
Nacked-by: Johannes Weiner [off-list ref]
On Wed, Aug 13, 2025 at 12:11 AM Shakeel Butt [off-list ref] wrote:
On Tue, Aug 12, 2025 at 05:58:30PM +0000, Kuniyuki Iwashima wrote:
quoted
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
When running under a non-root cgroup, this memory is also charged to the
memcg as "sock" in memory.stat.
Even when a memcg controls memory usage, sockets of such protocols are
still subject to global limits (e.g., /proc/sys/net/ipv4/tcp_mem).
This makes it difficult to accurately estimate and configure appropriate
global limits, especially in multi-tenant environments.
If all workloads were guaranteed to be controlled under memcg, the issue
could be worked around by setting tcp_mem[0~2] to UINT_MAX.
In reality, this assumption does not always hold, and processes that
belong to the root cgroup or opt out of memcg can consume memory up to
the global limit, becoming a noisy neighbour.
Processes running in root memcg (I am not sure what does 'opt out of
memcg means')
Sorry, I should've clarified memory.max==max (and same
up to all ancestors as you pointed out below) as opt-out,
where memcg works but has no effect.
means admin has intentionally allowed scenarios where
Not really intentionally, but rather reluctantly because the admin
cannot guarantee memory.max solely without tcp_mem=UINT_MAX.
We should not disregard the cause that the two mem accounting are
coupled now.
noisy neighbour situation can happen, so I am not really following your
argument here.
So basically here I meant with tcp_mem=UINT_MAX any process
can be noisy neighbour unnecessarily.
quoted
Let's decouple memcg from the global per-protocol memory accounting if
it has a finite memory.max (!= "max").
Why decouple only for some? (Also if you really want to check memcg
limits, you need to check limits for all ancestors and not just the
given memcg).
Oh, I assumed memory.max will be inherited to descendants.
Why not start with just two global options (maybe start with boot
parameter)?
Option 1: Existing behavior where memcg and global TCP accounting are
coupled.
Option 2: Completely decouple memcg and global TCP accounting i.e. use
mem_cgroup_sockets_enabled to either do global TCP accounting or memcg
accounting.
Keep the option 1 default.
I assume you want third option where a mix of these options can happen
i.e. some sockets are only accounted to a memcg and some are accounted
to both memcg and global TCP.
Yes because usually not all memcg have memory.max configured
and we do not want to allow unlimited TCP memory for them.
Option 2 works for processes in the root cgroup but doesn't for
processes in non-root cgroup with memory.max == max.
A good example is system processes managed by systemd where
we do not want to specify memory.max but want a global seatbelt.
Note this is how it works _now_, and we want to _preserve_ the case.
Does this make sense ? > why decouple only for some
I would recommend to make that a followup
patch series. Keep this series simple and non-controversial.
I can separate the series, but I'd like to make sure the
Option 2 is a must for you or Meta configured memory.max
for all cgroups ? I didn't think it's likely but if there's a real
use case, I'm happy to add a boot param.
The only diff would be boot param addition and the condition
change in patch 11 so simplicity won't change.
On Wed, Aug 13, 2025 at 6:00 AM Johannes Weiner [off-list ref] wrote:
On Tue, Aug 12, 2025 at 05:58:30PM +0000, Kuniyuki Iwashima wrote:
quoted
If all workloads were guaranteed to be controlled under memcg, the issue
could be worked around by setting tcp_mem[0~2] to UINT_MAX.
In reality, this assumption does not always hold, and processes that
belong to the root cgroup or opt out of memcg can consume memory up to
the global limit, becoming a noisy neighbour.
As per the last thread, this is not a supported usecase. Opting out of
memcg coverage for individual cgroups is a self-inflicted problem and
misconfiguration. There is *no* memory isolation *at all* on such
containers.
I think the commit message needs to be improved, but could
you read throughout the patch again ? I think you have the
same misunderstanding that Shakeel had and corrected here.
https://lore.kernel.org/netdev/jmbszz4m7xkw7fzolpusjesbreaczmr4i64kynbs3zcoehrkpj@lwso5soc4dh3/
---8<---
Initially, I thought the series introduced multiple modes, including an
option to exclude network memory from memcg accounting. However, if I
understand correctly, that is not the case—the opt-out applies only to
the global TCP/UDP accounting. That’s a relief, and I apologize for the
misunderstanding.
---8<---
This patch does NOT change how memcg is applied to sockets
but changes how _another_ memory accounting in the networking
layer is applied to sockets.
Currently, memcg AND the other mem accounting are applied
to socket buffers.
With/without this patch, memcg is _always_ applied to socket
buffers.
Also, there is _no_ behavioural change for _uncontrolled
containers_ that have been subject to the two memory
accounting. This behaviour hasn't been changed since
you added memcg support for the networking stack in
e805605c72102, and we want to _preserve_ this behaviour.
This change stop double-charging by opting out of _the
networking layer one_ because it interferes with memcg
and complicates configuration of memory.max and the
global networking limit.
Maybe their socket buffers is the only thing that happens
to matter to *you*, but this is in no way a generic, universal,
upstreamable solution. Knob or auto-detection is not the issue.
Nacked-by: Johannes Weiner [off-list ref]
Please let me know if this nack still applies with the
explanation above.
From: Johannes Weiner <hannes@cmpxchg.org> Date: 2025-08-13 20:21:52
On Wed, Aug 13, 2025 at 11:43:15AM -0700, Kuniyuki Iwashima wrote:
On Wed, Aug 13, 2025 at 6:00 AM Johannes Weiner [off-list ref] wrote:
This change stop double-charging by opting out of _the
networking layer one_ because it interferes with memcg
and complicates configuration of memory.max and the
global networking limit.
No, we do want the global limits as a backstop - even if every single
cgroup in the system has its own memory limit.
Sure, from a fairness POV, we want socket buffers accounted towards
the containers' memory footprint and subject to their limits.
But that doesn't imply that we can let the cgroup limit be the only
thing curbing an explosion in socket buffers.
This isn't about fairness, but about host stability.
The MM can easily get rid of file cache and heap pages, but it has
limited to no control over the socket buffer lifetime. If you split a
1TB host into 8 containers limited to ~128G, that doesn't mean you
want to allow up to 1TB of memory in socket buffers. That could make
low memory situations unrecoverable.
quoted
Maybe their socket buffers is the only thing that happens
to matter to *you*, but this is in no way a generic, universal,
upstreamable solution. Knob or auto-detection is not the issue.
Nacked-by: Johannes Weiner [off-list ref]
Please let me know if this nack still applies with the
explanation above.
Yes, for one I think it's an unacceptable behavioral change of the
sysctl semantics.
But my wider point is that I think you're trying to fix something that
is a direct result of a flawed approach to containerization, and it
would make much more sense to address that instead.
On Wed, Aug 13, 2025 at 11:19:31AM -0700, Kuniyuki Iwashima wrote:
On Wed, Aug 13, 2025 at 12:11 AM Shakeel Butt [off-list ref] wrote:
quoted
On Tue, Aug 12, 2025 at 05:58:30PM +0000, Kuniyuki Iwashima wrote:
quoted
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
When running under a non-root cgroup, this memory is also charged to the
memcg as "sock" in memory.stat.
Even when a memcg controls memory usage, sockets of such protocols are
still subject to global limits (e.g., /proc/sys/net/ipv4/tcp_mem).
This makes it difficult to accurately estimate and configure appropriate
global limits, especially in multi-tenant environments.
If all workloads were guaranteed to be controlled under memcg, the issue
could be worked around by setting tcp_mem[0~2] to UINT_MAX.
In reality, this assumption does not always hold, and processes that
belong to the root cgroup or opt out of memcg can consume memory up to
the global limit, becoming a noisy neighbour.
Processes running in root memcg (I am not sure what does 'opt out of
memcg means')
Sorry, I should've clarified memory.max==max (and same
up to all ancestors as you pointed out below) as opt-out,
where memcg works but has no effect.
quoted
means admin has intentionally allowed scenarios where
Not really intentionally, but rather reluctantly because the admin
cannot guarantee memory.max solely without tcp_mem=UINT_MAX.
We should not disregard the cause that the two mem accounting are
coupled now.
quoted
noisy neighbour situation can happen, so I am not really following your
argument here.
So basically here I meant with tcp_mem=UINT_MAX any process
can be noisy neighbour unnecessarily.
Only if there are processes in cgroups with unlimited memory limits.
I think you are still missing the point. So, let me be very clear:
Please stop using the "processes in cgroup with memory.max==max can be
source of isolation issues" argument. Having unlimited limit means you
don't want isolation. More importantly you don't really need this
argument for your work. It is clear (to me at least) that we want global
TCP memory accounting to be decoupled from memcg accounting. Using the
flawed argument is just making your series controversial.
[...]
quoted
Why not start with just two global options (maybe start with boot
parameter)?
Option 1: Existing behavior where memcg and global TCP accounting are
coupled.
Option 2: Completely decouple memcg and global TCP accounting i.e. use
mem_cgroup_sockets_enabled to either do global TCP accounting or memcg
accounting.
Keep the option 1 default.
I assume you want third option where a mix of these options can happen
i.e. some sockets are only accounted to a memcg and some are accounted
to both memcg and global TCP.
Yes because usually not all memcg have memory.max configured
and we do not want to allow unlimited TCP memory for them.
Option 2 works for processes in the root cgroup but doesn't for
processes in non-root cgroup with memory.max == max.
A good example is system processes managed by systemd where
we do not want to specify memory.max but want a global seatbelt.
Note this is how it works _now_, and we want to _preserve_ the case.
Does this make sense ? > why decouple only for some
I hope I am very clear to stop using the memory.max == max argument.
quoted
I would recommend to make that a followup
patch series. Keep this series simple and non-controversial.
I can separate the series, but I'd like to make sure the
Option 2 is a must for you or Meta configured memory.max
for all cgroups ? I didn't think it's likely but if there's a real
use case, I'm happy to add a boot param.
The only diff would be boot param addition and the condition
change in patch 11 so simplicity won't change.
I am not sure if option 2 will be used by Meta or someone else, so no
objection from me to not pursue it. However I don't want some possibly
userspace policy to opt-in in one or the other accounting mechanism in
the kernel.
What I think is the right approach is to have BPF struct ops based
approach with possible callback 'is this socket under pressure' or maybe
'is this socket isolated' and then you can do whatever you want in those
callbacks. In this way your can follow the same approach of caching the
result in kernel (lower bits of sk->sk_memcg).
I am CCing bpf list to get some suggestions or concerns on this
approach.
From: Martin KaFai Lau <martin.lau@linux.dev> Date: 2025-08-14 00:54:56
On 8/13/25 1:53 PM, Shakeel Butt wrote:
What I think is the right approach is to have BPF struct ops based
approach with possible callback 'is this socket under pressure' or maybe
'is this socket isolated' and then you can do whatever you want in those
callbacks. In this way your can follow the same approach of caching the
result in kernel (lower bits of sk->sk_memcg).
I am CCing bpf list to get some suggestions or concerns on this
approach.
I have quickly looked at the set. In patch 11, it sets a bit in sk->sk_memcg.
On the bpf side, there are already cgroup bpf progs that can do bpf_setsockopt
on a sk, so the same can be done here. The bpf_setsockopt does not have to set
option/knob that is only available in the uapi in case we don't want to expose
this to the user space.
The cgroup bpf prog (BPF_CGROUP_INET_SOCK_CREATE) can already be run when a
"inet" sock is created. This hook (i.e. attach_type) does not have access to
bpf_setsockopt but should be easy to add.
For more comprehensive mem charge policy that needs new bpf hook, that probably
will need struct_ops instead of another cgroup attach_type but that will be
implementation details.
On Wed, Aug 13, 2025 at 5:55 PM Martin KaFai Lau [off-list ref] wrote:
On 8/13/25 1:53 PM, Shakeel Butt wrote:
quoted
What I think is the right approach is to have BPF struct ops based
approach with possible callback 'is this socket under pressure' or maybe
'is this socket isolated' and then you can do whatever you want in those
callbacks. In this way your can follow the same approach of caching the
result in kernel (lower bits of sk->sk_memcg).
I am CCing bpf list to get some suggestions or concerns on this
approach.
I have quickly looked at the set. In patch 11, it sets a bit in sk->sk_memcg.
On the bpf side, there are already cgroup bpf progs that can do bpf_setsockopt
on a sk, so the same can be done here. The bpf_setsockopt does not have to set
option/knob that is only available in the uapi in case we don't want to expose
this to the user space.
The cgroup bpf prog (BPF_CGROUP_INET_SOCK_CREATE) can already be run when a
"inet" sock is created. This hook (i.e. attach_type) does not have access to
bpf_setsockopt but should be easy to add.
Okay, I will try the bpf_setsockopt() approach.
Should I post patch 1-10 to net-next separately ?
They are pure net material to gather memcg code under CONFIG_MEMCG.
For more comprehensive mem charge policy that needs new bpf hook, that probably
will need struct_ops instead of another cgroup attach_type but that will be
implementation details.
From: Michal Koutný <mkoutny@suse.com> Date: 2025-08-14 12:30:29
Hello.
On Tue, Aug 12, 2025 at 05:58:19PM +0000, Kuniyuki Iwashima [off-list ref] wrote:
When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets
sk->sk_memcg based on the current task.
MPTCP subflow socket creation is triggered from userspace or
an in-kernel worker.
I somewhat remembered
d752a4986532c ("net: memcg: late association of sock to memcg")
but IIUC this MPTCP codepath, the socket would never be visible to
userspace nor manipulated from a proper process context, so there is no
option to defer the association in similar fashion, correct?
Then, I wonder whether this isn't a scenario for
o = set_active_memcg(sk->sk_memcg);
newsk = sk_alloc();
...
set_active_memcg(o);
i.e. utilize the existing remote charging infra instead of introducing
specific mem_cgroup_sk_inherit() helper.
Regards,
Michal
On Wed, Aug 13, 2025 at 09:34:01PM -0700, Kuniyuki Iwashima wrote:
On Wed, Aug 13, 2025 at 5:55 PM Martin KaFai Lau [off-list ref] wrote:
quoted
On 8/13/25 1:53 PM, Shakeel Butt wrote:
quoted
What I think is the right approach is to have BPF struct ops based
approach with possible callback 'is this socket under pressure' or maybe
'is this socket isolated' and then you can do whatever you want in those
callbacks. In this way your can follow the same approach of caching the
result in kernel (lower bits of sk->sk_memcg).
I am CCing bpf list to get some suggestions or concerns on this
approach.
I have quickly looked at the set. In patch 11, it sets a bit in sk->sk_memcg.
On the bpf side, there are already cgroup bpf progs that can do bpf_setsockopt
on a sk, so the same can be done here. The bpf_setsockopt does not have to set
option/knob that is only available in the uapi in case we don't want to expose
this to the user space.
The cgroup bpf prog (BPF_CGROUP_INET_SOCK_CREATE) can already be run when a
"inet" sock is created. This hook (i.e. attach_type) does not have access to
bpf_setsockopt but should be easy to add.
Okay, I will try the bpf_setsockopt() approach.
Should I post patch 1-10 to net-next separately ?
They are pure net material to gather memcg code under CONFIG_MEMCG.
Hello.
On Tue, Aug 12, 2025 at 05:58:19PM +0000, Kuniyuki Iwashima [off-list ref] wrote:
quoted
When sk_alloc() allocates a socket, mem_cgroup_sk_alloc() sets
sk->sk_memcg based on the current task.
MPTCP subflow socket creation is triggered from userspace or
an in-kernel worker.
I somewhat remembered
d752a4986532c ("net: memcg: late association of sock to memcg")
but IIUC this MPTCP codepath, the socket would never be visible to
userspace nor manipulated from a proper process context, so there is no
option to defer the association in similar fashion, correct?
Then, I wonder whether this isn't a scenario for
o = set_active_memcg(sk->sk_memcg);
newsk = sk_alloc();
...
set_active_memcg(o);
i.e. utilize the existing remote charging infra instead of introducing
specific mem_cgroup_sk_inherit() helper.
Sounds good to me. sock_create_kern() is much larger than
other set_active_memcg() users, most of which just wrap simple
alloc() functions, but probably that's okay.
I'll use this in the next version.
Thanks!
---8<---
@@ -1717,14 +1717,6 @@ static void mptcp_attach_cgroup(struct sock *parent, struct sock *child)/* only the additional subflows created by kworkers have to be modified */if(cgroup_id(sock_cgroup_ptr(parent_skcd))!=cgroup_id(sock_cgroup_ptr(child_skcd))){-#ifdef CONFIG_MEMCG-structmem_cgroup*memcg=parent->sk_memcg;--mem_cgroup_sk_free(child);-if(memcg&&css_tryget(&memcg->css))-child->sk_memcg=memcg;-#endif /* CONFIG_MEMCG */-cgroup_sk_free(child_skcd);*child_skcd=*parent_skcd;cgroup_sk_clone(child_skcd);
@@ -1757,6 +1749,7 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,{structmptcp_subflow_context*subflow;structnet*net=sock_net(sk);+structmem_cgroup*memcg;structsocket*sf;interr;
@@ -1766,7 +1759,9 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,if(unlikely(!sk->sk_socket))return-EINVAL;+memcg=set_active_memcg(sk->sk_memcg);err=sock_create_kern(net,family,SOCK_STREAM,IPPROTO_TCP,&sf);+set_active_memcg(memcg);if(err)returnerr;---8<---