netdev - Re: [PATCH v3] memcg: expose socket memory pressure in a cgroup

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: <878ca484-a045-4abb-a5bd-7d5ae82607de@cdn77.com>
Date: Wed, 23 Jul 2025 10:58:10 +0200
From: Daniel Sedlak <daniel.sedlak@...77.com>
To: Michal Koutný <mkoutny@...e.com>,
 Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Kuniyuki Iwashima <kuniyu@...gle.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, Jonathan Corbet <corbet@....net>,
 Neal Cardwell <ncardwell@...gle.com>, David Ahern <dsahern@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Yosry Ahmed <yosry.ahmed@...ux.dev>, linux-mm@...ck.org,
 netdev@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
 Michal Hocko <mhocko@...nel.org>, Roman Gushchin <roman.gushchin@...ux.dev>,
 Muchun Song <muchun.song@...ux.dev>, cgroups@...r.kernel.org,
 Matyas Hurtik <matyas.hurtik@...77.com>
Subject: Re: [PATCH v3] memcg: expose socket memory pressure in a cgroup

On 7/23/25 10:38 AM, Michal Koutný wrote:
> On Tue, Jul 22, 2025 at 01:11:05PM -0700, Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>>>> 1 second is the current implementation and it can be more if the memcg
>>>> remains in memory pressure. Regarding usefullness I think the periodic
>>>> stat collectors (like cadvisor or Google's internal borglet+rumbo) would
>>>> be interested in scraping this interface.
>>>
>>> I think the cumulative counter suggested above is better at least.
>>
>> It is tied to the underlying implementation. If we decide to use, for
>> example, PSI in future, what should this interface show?
> 
> Actually, if it was exposed as cummulative time under pressure (not
> cummulative events), that's quite similar to PSI.

I think overall the cumulative counter is better than just signaling 1 
or 0, but it lacks the time information (if not scraped periodically). 
In addition, it may oscillate between under_pressure=true/false rather 
quickly so the cumulative counter would catch this.

To me, introducing the new PSI for sockets (like for CPU, IO, memory), 
would be slightly better than cumulative counter because PSI can have 
the timing information without frequent periodic scrapes. So it may help 
with live debugs.

However, if we were to just add a new counter to the memory.stat in each 
cgroup, then it would be easier to do so?