linux-kernel - Re: [PATCH] memcg: add hierarchical effective limits for v2

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z9hkq7pet9m-WrZY@slm.duckdns.org>
Date: Mon, 17 Mar 2025 08:06:35 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Johannes Weiner <hannes@...xchg.org>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Michal Koutný <mkoutny@...e.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	"T.J. Mercier" <tjmercier@...gle.com>,
	Michal Hocko <mhocko@...nel.org>,
	Muchun Song <muchun.song@...ux.dev>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
	Meta kernel team <kernel-team@...a.com>
Subject: Re: [PATCH] memcg: add hierarchical effective limits for v2

Hello,

On Sun, Mar 16, 2025 at 06:12:14PM -0700, Andrew Morton wrote:
> On Wed, 26 Feb 2025 22:51:55 -0500 Johannes Weiner <hannes@...xchg.org> wrote:
> 
> > > > start only with memory.max as
> > > > that has some usecases).
> > > 
> > > Yes, I can link [2] with more info added to the commit message.
> > > 
> > > Johannes, do you want effective interface for low and min as well or for
> > > now just keep the current targeted interfaces?
> > 
> > I think it would make sense to do min, low, high, max for memory in
> > one go, as a complete new feature, rather than doing them one by one.
> > 
> > Tejun, what's your take on this, considering other controllers as
> > well? Does that seem like a reasonable solution to address the "I'm in
> > a namespace and can't see my configuration" problem?
> 
> I guess Tejun missed this.
> 
> It seems that more think time is needed on this patch?

Oh yes, I did. My apologies and thanks for the poking.

I'm a bit doubtful that simply compounding the configured values and
presenting them to the nested cgroup would be a good solution here. It does
add more information but given that the same values can indicate multiple
widely differing situations, I'm unsure how much value they would provide.
Wouldn't it be just providing more numbers to be confused about?

My intuition is that most applications would want a single number to base
sizing decisions on and I don't know how they could handle the gap between
e.g. low and max without further information on configuration intent.

If someone has to provide the configuration intent anyway, why not just let
them provide the single number that the application would care about - the
intended memory amount for that application or container? We can provide a
dedicated cgroup file for it or admin can just set an xattr on the cgroup
directory. Maybe the xattr perm checks can be improved so that it aligns
better with subtree delegations for the latter.

ie. I feel like .effective's are us trying to do *something* even if that
thing doesn't actually solve the problem. I'm not hard set on this opinion
tho and would really appreciate counter arguments.

Thanks.

-- 
tejun