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.
