Messages in this thread | | | Date | Thu, 9 Nov 2023 18:55:09 +0800 | Subject | Re: [RFC 0/4] Introduce unbalance proactive reclaim | From | Huan Yang <> |
| |
在 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
| |