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

[Davidlohr Bueso]

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.