linux-kernel - Re: [RFC] mm/swap.c: Enable promotion of unmapped MGLRU page cache 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: <0b4052bb-5ad3-42a3-a81e-e81d722036b7@linux.ibm.com>
Date: Thu, 16 Jan 2025 16:46:46 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: Gregory Price <gourry@...rry.net>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Yu Zhao <yuzhao@...gle.com>,
        Ritesh Harjani <ritesh.list@...il.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        David Hildenbrand <david@...hat.com>,
        Huang Ying <ying.huang@...ux.alibaba.com>,
        Johannes Weiner <hannes@...xchg.org>
Subject: Re: [RFC] mm/swap.c: Enable promotion of unmapped MGLRU page cache
 pages


On 1/15/25 21:39, Gregory Price wrote:
> On Wed, Jan 15, 2025 at 06:06:25AM -0600, Donet Tom wrote:
> ... snip ...
>
> Thank you for taking the time to do this, I don't have enough background
> with MGLRU to have done this quickly.  I'll pull this onto my branch and
> carry it if you don't mind so we can keep things tracked.
>
> I'll send you an updated RFC before i send out v4 and add appropriate tags.
Sure. Thank you.
>
>> This difference also impacts read latency:
>>
>> For MGLRU, the first read shows higher latency due to the combined
>> overhead of accessing a lower tier and performing promotion.
>>
>> For LRU, the first 3–4 reads typically exhibit lower latency since
>> promotion does not occur immediately.
>>
> Do you have a thought on a good test we can use to compare these
> strategies?
I am also thinking on the same. I will come back with some tests which
can compare these strategies.
>
> We decided against promotion on first-access because there are many
> easy-to-imagine scenarios where that will clearly harm performance.
Yes, I agree. After the first access, it gets promoted, but if those pages
are not accessed afterward, it will become an overhead.
I will check if we have any mechanism to restrict it.
>
> We're planning to do some workload testing soon so we can get actual
> benefit numbers.
Could you please let me know what workload you are planning?
I can try it on my system as well.
>
>> +promo_candid:
>> +	if (!folio_test_isolated(folio) &&
>> +		(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) &&
>> +		numa_pagecache_promotion_enabled) {
> I am considering putting this in some inline wrapper with some likely()
> tags to clean this up a bit and optimize the fall-through cases since
> i've seen some measurable differences when left as-is.
Sounds good to me.
>
> Thoughts on this are welcome
>
>> +		memcg = folio_memcg(folio);
>> +		if (memcg) {
> Also curious, why only promote when the folio is a member of a memcg?

I missed non memcg pages. I will send a V2 with that.

~Donet

>
> ~Gregory