linux-kernel - Re: [PATCH] mm, proc: collect percpu free pages into the free pages

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: <ZuBFlMgyqfXEph2g@tiehlicka>
Date: Tue, 10 Sep 2024 15:11:48 +0200
From: Michal Hocko <mhocko@...e.com>
To: mawupeng <mawupeng1@...wei.com>
Cc: ying.huang@...el.com, akpm@...ux-foundation.org,
	mgorman@...hsingularity.net, dmaluka@...omium.org,
	liushixin2@...wei.com, wangkefeng.wang@...wei.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm, proc: collect percpu free pages into the free pages

On Tue 10-09-24 20:11:36, mawupeng wrote:
> 
> 
> On 2024/9/4 15:28, Michal Hocko wrote:
> > On Wed 04-09-24 14:49:20, mawupeng wrote:
[...]
> >> Current the problem is amount the pcp, which can increase to 4.6%(24644M)
> >> of the total 512G memory.
> > 
> > Why is that a problem? 
> 
> MemAvailable
>               An estimate of how much memory is available for starting new
>               applications, without swapping. Calculated from MemFree,
>               SReclaimable, the size of the file LRU lists, and the low
>               watermarks in each zone.
> 
> The PCP memory is essentially available memory and will be reclaimed before OOM.
> In essence, it is not fundamentally different from reclaiming file pages, as both
> are reclaimed within __alloc_pages_direct_reclaim.

It is not _fundamentally_ different but the reclaim trigger bar is
different (much higher). You might get into swapping while still keeping
pcp cache available for example.

MemAvailable has been an estimate. Time has proven not a great one as
it is hard to set expectations around that. You are focusing on pcp
caches but there others that might are not covered (e.g. networking
stack can do a lot of caching on its own). MemAvailable will never be
perfect and if you are hitting limits of its usefulness I would
recommend finding a different way to achieve your goals (which are still
not really clear to me TBH). 
-- 
Michal Hocko
SUSE Labs