Re: [PATCH resend] memcg: introduce per-memcg reclaim interface

[Michal Hocko]

On Wed 06-04-22 14:32:24, Huang, Ying wrote:
[...]
> I think we should define the interface not from the current
> implementation point of view, but from the requirement point of view.

Agreed!

> For proactive reclaim, per my understanding, the requirement is,
> 
>   we found that there's some cold pages in some workloads, so we can
>   take advantage of the proactive reclaim to reclaim some pages so that
>   other workload can use the freed memory.

We are talking about memcg here so this is not as much a matter of free
memory as it is to decrease the amount of charged memory. Demotion
cannot achieve that.

> For proactive demotion, per my understanding, the requirement could be,
> 
>   We found that there's some cold pages in fast memory (e.g. DRAM) in
>   some workloads, so we can take advantage of the proactive demotion to
>   demote some pages so that other workload can use the freed fast
>   memory.  Given the DRAM partition support Tim (Cced) is working on.

Yes, this is essentially a kernel assisted memory migration. Userspace
can migrate memory but the issue is that it doesn't have any information
on the aging so the migration has hard time to find suitable memory to
migrate. If we really need this functionality then it would deserve a
separate interface IMHO.

-- 
Michal Hocko
SUSE Labs