netdev - Re: [PATCH v1 net-next 13/13] net-memcg: Allow decoupling memcg from global protocol memory accounting.

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: <87pldhf4mf.fsf@linux.dev>
Date: Wed, 30 Jul 2025 19:58:32 -0700
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: "David S. Miller" <davem@...emloft.net>,  Eric Dumazet
 <edumazet@...gle.com>,  Jakub Kicinski <kuba@...nel.org>,  Neal Cardwell
 <ncardwell@...gle.com>,  Paolo Abeni <pabeni@...hat.com>,  Willem de
 Bruijn <willemb@...gle.com>,  Matthieu Baerts <matttbe@...nel.org>,  Mat
 Martineau <martineau@...nel.org>,  Johannes Weiner <hannes@...xchg.org>,
  Michal Hocko <mhocko@...nel.org>,  Shakeel Butt <shakeel.butt@...ux.dev>,
  Andrew Morton <akpm@...ux-foundation.org>,  Simon Horman
 <horms@...nel.org>,  Geliang Tang <geliang@...nel.org>,  Muchun Song
 <muchun.song@...ux.dev>,  Kuniyuki Iwashima <kuni1840@...il.com>,
  netdev@...r.kernel.org,  mptcp@...ts.linux.dev,  cgroups@...r.kernel.org,
  linux-mm@...ck.org
Subject: Re: [PATCH v1 net-next 13/13] net-memcg: Allow decoupling memcg
 from global protocol memory accounting.

Kuniyuki Iwashima <kuniyu@...gle.com> writes:

> 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 memory usage is controlled by memcg, sockets using 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 a single workload
> that opts 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.
>
> This simplifies memcg configuration while keeping the global limits
> within a reasonable range.

I don't think it should be a memcg feature. In fact, it doesn't have
much to do with cgroups at all (it's not hierarchical, it doesn't
control the resource allocation, and in the end it controls an
alternative to memory cgroups memory accounting system).

Instead, it can be a per-process prctl option.

(Assuming the feature is really needed - I'm also curious why some
processes have to be excluded from the memcg accounting - it sounds like
generally a bad idea).

Thanks