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] [day] [month] [year] [list]

Message-ID: <ZyT7QebITxOKNi_c@casper.infradead.org>
Date: Fri, 1 Nov 2024 16:01:05 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Stepanov Anatoly <stepanov.anatoly@...wei.com>
Cc: Michal Hocko <mhocko@...e.com>,
	Gutierrez Asier <gutierrez.asier@...wei-partners.com>,
	akpm@...ux-foundation.org, david@...hat.com, ryan.roberts@....com,
	baohua@...nel.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,
	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,
	nikita.panov@...wei-partners.com
Subject: Re: [RFC PATCH 0/3] Cgroup-based THP control

On Thu, Oct 31, 2024 at 05:37:12PM +0300, Stepanov Anatoly wrote:
> Don't get us wrong, we're not trying to push this into memcg specifically. 
> We're just trying to find a proper/friendly way to control
> THP mode for a group of processes (which can be tasks without common parent).
> 
> May be if the process grouping logic were decoupled from hierarchical resource control
> logic, it could be possible to gather multiple process, and batch-control some task properties.
> But it would require to build kind of task properties system, where
> a given set of properties can be flexibly assigned to one or more tasks.
> 
> Anyway, i think we gonna try alternative
> approaches first.(prctl, process_madvise).

I oppose all of these approaches.  They are fundamentally misguided.
You're trying to blame sysadmins for our inadequacies as programmers.
All of this should be automatic.  Certainly the kernel will make mistakes
and not use the perfectly optimal size at all times, but it should be able
to get close to optimal.  Please, focus your efforts on allocating memory
of the right size, not on this fake problem of "we only have 235 THPs
available and we must make sure that the right process gets 183 of them".