lkml.org 
[lkml]   [2023]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC 0/4] Introduce unbalance proactive reclaim
From

在 2023/11/9 18:39, Michal Hocko 写道:
> [Some people who received this message don't often get email from mhocko@suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Thu 09-11-23 18:29:03, Huan Yang wrote:
>> HI Michal Hocko,
>>
>> Thanks for your suggestion.
>>
>> 在 2023/11/9 17:57, Michal Hocko 写道:
>>> [Some people who received this message don't often get email from mhocko@suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> On Thu 09-11-23 11:38:56, Huan Yang wrote:
>>> [...]
>>>>> If 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.
>>> If that is the case and this is mostly application centric (which you
>>> seem to be suggesting) then why don't you use madvise(MADV_PAGEOUT)
>>> instead.
>> Madvise may not be applicable in this scenario.(IMO)
>>
>> 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.)
> You are proposing an extension to the pro-active reclaim interface so
> 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.
There is a key point here. We want to use the grouping policy of memcg
to perform
proactive reclamation with certain tendencies. Your suggestion is to
reclaim memory
by scanning the task process space. However, in the mobile field, memory
is usually
viewed at the granularity of an APP.

Therefore, after an APP is frozen, we hope to reclaim memory uniformly
according
to the pre-grouped APP processes.

Of course, as you suggested, madvise can also achieve this, but
implementing it in
the agent may be more complex.(In terms of achieving the same goal,
using memcg
to group all the processes of an APP and perform proactive reclamation
is simpler
than using madvise and scanning multiple processes of an application
using an agent?)

>
> --
> Michal Hocko
> SUSE Labs

--
Thanks,
Huan Yang

\
 
 \ /
  Last update: 2023-11-20 13:54    [W:0.066 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site