在 2023/11/9 20:45, 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 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@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.
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
