linux-kernel - Re: [PATCH -next] mm: introduce per-node proactive reclaim interface

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: <20240910163115.cg26kenlejlkmnsp@offworld>
Date: Tue, 10 Sep 2024 09:31:15 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Michal Hocko <mhocko@...e.com>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, rientjes@...gle.com,
	yosryahmed@...gle.com, hannes@...xchg.org, almasrymina@...gle.com,
	roman.gushchin@...ux.dev, gthelen@...gle.com, dseo3@....edu,
	a.manzanares@...sung.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] mm: introduce per-node proactive reclaim interface

On Mon, 09 Sep 2024, Michal Hocko wrote:

>On Wed 04-09-24 09:27:40, Davidlohr Bueso wrote:
>> 1. Users who do not use memcg can benefit from proactive reclaim.
>
>It would be great to have some specific examples here. Is there a
>specific reason memcg is not used?

I know cases of people wanting to use this to free up fast memory
without incurring in extra latency spikes before a promotion occurs.
I do not have details as to why memcg is not used. I can also see
this for virtual machines running on specific nodes, reclaiming "extra"
memory based on wss and qos, as well as potential hibernation optimizations.

>> 2. Proactive reclaim on top tiers will trigger demotion, for which
>> memory is still byte-addressable. Reclaiming on the bottom nodes
>> will trigger evicting to swap (the traditional sense of reclaim).
>> This follows the semantics of what is today part of the aging process
>> on tiered memory, mirroring what every other form of reclaim does
>> (reactive and memcg proactive reclaim). Furthermore per-node proactive
>> reclaim is not as susceptible to the memcg charging problem mentioned
>> above.
>>
>> 3. Unlike memcg, there should be no surprises of callers expecting
>> reclaim but instead got a demotion. Essentially relying on behavior
>> of shrink_folio_list() after 6b426d071419 (mm: disable top-tier
>> fallback to reclaim on proactive reclaim), without the expectations
>> of try_to_free_mem_cgroup_pages().
>
>I am not sure I understand. If you demote then you effectively reclaim
>because you free up memory on the specific node. Or do I just misread
>what you mean? Maybe you meant to say that the overall memory
>consumption on all nodes is not affected?

Yes, exactly, that is what I meant to say.

>Your point 4 and 5 follows up on this so we should better clarify that
>before going there.