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: <26e53efe-7a54-499a-8d3f-345d29d90348@huawei.com>
Date: Tue, 10 Sep 2024 20:11:36 +0800
From: mawupeng <mawupeng1@...wei.com>
To: <mhocko@...e.com>
CC: <mawupeng1@...wei.com>, <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 2024/9/4 15:28, Michal Hocko wrote:
> 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? 

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. Therefore, why shouldn't it be
included in MemAvailable to avoid confusion.

__alloc_pages_direct_reclaim
  __perform_reclaim
  if (!page && !drained)
    drain_all_pages(NULL);


> 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?