[Some people who received this message don't often get email from mhocko@xxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]There is a key point here. We want to use the grouping policy of memcg to perform
On Thu 09-11-23 18:29:03, Huan Yang wrote:
HI Michal Hocko,You are proposing an extension to the pro-active reclaim interface so
Thanks for your suggestion.
在 2023/11/9 17:57, Michal Hocko 写道:
[Some people who received this message don't often get email from mhocko@xxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]Madvise may not be applicable in this scenario.(IMO)
On Thu 09-11-23 11:38:56, Huan Yang wrote:
[...]
If that is the case and this is mostly application centric (which youIf so, is it better only to reclaim private anonymous pages explicitly?Yes, in practice, we only proactively compress anonymous pages and do not
want to touch file pages.
seem to be suggesting) then why don't you use madvise(MADV_PAGEOUT)
instead.
This feature is aimed at a core goal, which is to compress the anonymous
pages
of frozen applications.
How to detect that an application is frozen and determine which pages can be
safely reclaimed is the responsibility of the policy part.
Setting madvise for an application is an active behavior, while the above
policy
is a passive approach.(If I misunderstood, please let me know if there is a
better
way to set madvise.)
this is an active behavior pretty much by definition. So I am really not
following you here. Your agent can simply scan the address space of the
application it is going to "freeze" and call pidfd_madvise(MADV_PAGEOUT)
on the private memory is that is really what you want/need.
--
Michal Hocko
SUSE Labs