linux-kernel - Re: [RFC PATCH 0/3] Cgroup-based THP control

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: <ZyJGhKu1FL1ZfCcs@chrisdown.name>
Date: Wed, 30 Oct 2024 14:45:24 +0000
From: Chris Down <chris@...isdown.name>
To: gutierrez.asier@...wei-partners.com
Cc: akpm@...ux-foundation.org, david@...hat.com, ryan.roberts@....com,
	baohua@...nel.org, willy@...radead.org, peterx@...hat.com,
	hannes@...xchg.org, hocko@...nel.org, roman.gushchin@...ux.dev,
	shakeel.butt@...ux.dev, muchun.song@...ux.dev,
	cgroups@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, stepanov.anatoly@...wei.com,
	alexander.kozhevnikov@...wei-partners.com, guohanjun@...wei.com,
	weiyongjun1@...wei.com, wangkefeng.wang@...wei.com,
	judy.chenhui@...wei.com, yusongping@...wei.com,
	artem.kuzin@...wei.com, kang.sun@...wei.com
Subject: Re: [RFC PATCH 0/3] Cgroup-based THP control

gutierrez.asier@...wei-partners.com writes:
>New memcg files are exposed: memory.thp_enabled and memory.thp_defrag, which
>have completely the same format as global THP enabled/defrag.

cgroup controls exist because there are things we want to do for an entire 
class of processes (group OOM, resource control, etc). Enabling or disabling 
some specific setting is generally not one of them, hence why we got rid of 
things like per-cgroup vm.swappiness. We know that these controls do not 
compose well and have caused a lot of pain in the past. So my immediate 
reaction is a nack on the general concept, unless there's some absolutely 
compelling case here.

I talked a little at Kernel Recipes last year about moving away from sysctl and 
other global interfaces and making things more granular. Don't get me wrong, I 
think that is a good thing (although, of course, a very large undertaking) -- 
but it is a mistake to overload the amount of controls we expose as part of the 
cgroup interface.

I am up for thinking overall about how we can improve the state of global 
tunables to make them more granular overall, but this can't set a precedent as 
the way to do it.