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

[Huan Yang]

在 2023/11/9 17:53, 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 ]
>
> 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@xxxxxxxx. 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