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: <ZtgMHFQ4NwdvL7_e@tiehlicka>
Date: Wed, 4 Sep 2024 09:28:28 +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 Wed 04-09-24 14:49:20, mawupeng wrote:
> 
> 
> On 2024/9/3 16:09, Michal Hocko wrote:
> > On Tue 03-09-24 09:50:48, mawupeng wrote:
> >>> Drain remote PCP may be not that expensive now after commit 4b23a68f9536
> >>> ("mm/page_alloc: protect PCP lists with a spinlock").  No IPI is needed
> >>> to drain the remote PCP.
> >>
> >> This looks really great, we can think a way to drop pcp before goto slowpath
> >> before swap.
> > 
> > We currently drain after first unsuccessful direct reclaim run. Is that
> > insufficient? 
> 
> The reason i said the drain of pcp is insufficient or expensive is based
> on you comment[1] :-）. Since IPIs is not requiered since commit 4b23a68f9536
> ("mm/page_alloc: protect PCP lists with a spinlock"). This could be much
> better.
> 
> [1]: https://lore.kernel.org/linux-mm/ZWRYZmulV0B-Jv3k@tiehlicka/

there are other reasons I have mentioned in that reply which play role
as well.

> > Should we do a less aggressive draining sooner? Ideally
> > restricted to cpus on the same NUMA node maybe? Do you have any specific
> > workloads that would benefit from this?
> 
> Current the problem is amount the pcp, which can increase to 4.6%(24644M)
> of the total 512G memory.

Why is that a problem? Just because some tools are miscalculating memory
pressure because they are based on MemAvailable? Or does this lead to
performance regressions on the kernel side? In other words would the
same workload behaved better if the amount of pcp-cache was reduced
without any userspace intervention?
-- 
Michal Hocko
SUSE Labs