Messages in this thread | | | Date | Thu, 9 Nov 2023 21:10:26 +0800 | Subject | Re: [RFC 0/4] Introduce unbalance proactive reclaim | From | Huan Yang <> |
| |
在 2023/11/9 20:45, 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:55:09, Huan Yang wrote: >> 在 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. > I was asking about default reclaim behavior not madvise here. Sorry for the misunderstand. > >>> 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. > As already pointed out in other reply, make sure you explain this so > that we, who are not active in mobile field, can understand the metric, > how it is affected by the tooling relying on this interface. OK. > >> 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. > cgroup v1 is in maintenance mode and new extension would need to pass > even a higher feasibility test than v2 based interface. Also make sure > that you are testing the current upstream kernel. OK, if patchset v2 expect, I will change work into cgroup v2 and give test data. > > Also let me stress out that you are proposing an extension to the user > visible API and we will have to maintain that for ever. So make sure > your justification is solid and understandable. Thank you very much for your explanation. Let's focus on these discussions in another email. > -- > Michal Hocko > SUSE Labs
-- Thanks, Huan Yang
| |