Re: [RFC 0/4] Introduce unbalance proactive reclaim

[Huan Yang <link@vivo.com>]

在 2023/11/9 17:53, 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 09:56:46, Huan Yang wrote:
>> 在 2023/11/8 22:06, 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 Wed 08-11-23 14:58:11, Huan Yang wrote:
>>>> In some cases, we need to selectively reclaim file pages or anonymous
>>>> pages in an unbalanced manner.
>>>>
>>>> For example, when an application is pushed to the background and frozen,
>>>> it may not be opened for a long time, and we can safely reclaim the
>>>> application's anonymous pages, but we do not want to touch the file pages.
>>> Could you explain why? And also why do you need to swap out in that
>>> case?
>> When an application is frozen, it usually means that we predict that
>> it will not be used for a long time. In order to proactively save some
>> memory, our strategy will choose to compress the application's private
>> data into zram. And we will also select some of the cold application
>> data that we think is in zram and swap it out.
>>
>> The above operations assume that anonymous pages are private to the
>> application.  After the application is frozen, compressing these pages
>> into zram can save memory to some extent without worrying about
>> frequent refaults.
> Why don't you rely on the default reclaim heuristics? In other words do
As I mentioned earlier, the madvise approach may not be suitable for my 
needs.
> you have any numbers showing that a selective reclaim results in a much

In the mobile field, we have a core metric called application residency.

This mechanism can help us improve the application residency if we can 
provide
a good freeze detection and proactive reclamation policy.

I can only provide specific data from our internal tests, and it may be 
older data,
and it tested using cgroup v1:

In 12G ram phone, app residency improve from 29 to 38.


> better behavior? How do you evaluate that?
>
>> And the cost of refaults on zram is lower than that of IO.
>>
>>
>>>> This patchset extends the proactive reclaim interface to achieve
>>>> unbalanced reclamation. Users can control the reclamation tendency by
>>>> inputting swappiness under the original interface. Specifically, users
>>>> can input special values to extremely reclaim specific pages.
>>> Other have already touched on this in other replies but v2 doesn't have
>>> a per-memcg swappiness
>>>
>>>> Example:
>>>>         echo "1G" 200 > memory.reclaim (only reclaim anon)
>>>>           echo "1G" 0  > memory.reclaim (only reclaim file)
>>>>           echo "1G" 1  > memory.reclaim (only reclaim file)
>>>>
>>>> Note that when performing unbalanced reclamation, the cgroup swappiness
>>>> will be temporarily adjusted dynamically to the input value. Therefore,
>>>> if the cgroup swappiness is further modified during runtime, there may
>>>> be some errors.
>>> In general this is a bad semantic. The operation shouldn't have side
>>> effect that are potentially visible for another operation.
>> So, maybe pass swappiness into sc and keep a single reclamation ensure that
>> swappiness is not changed?
> That would be a much saner approach.
>
>> Or, it's a bad idea that use swappiness to control unbalance reclaim.
> Memory reclaim is not really obliged to consider swappiness. In fact the
> actual behavior has changed several times in the past and it is safer to
> assume this might change in the future again.
Thank you for the guidance.
>
> --
> Michal Hocko
> SUSE Labs

-- 
Thanks,
Huan Yang