Messages in this thread | | | Date | Fri, 20 Oct 2023 09:57:59 +0800 | Subject | Re: [PATCH 0/3 RESEND] Per memcg lru_gen node stat | From | Huan Yang <> |
| |
在 2023/10/20 0:01, T.J. Mercier 写道: > [你通常不会收到来自 tjmercier@google.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification,以了解这一点为什么很重要] > > On Wed, Oct 18, 2023 at 7:32 PM Huan Yang <link@vivo.com> wrote: >>> Android can't use debugfs in production, but I >>> think we'd prefer to use memory.reclaim for eviction anyway because it >>> respects memcg limits and reclaims from slab. >> Yes, shrink control this actually can use proactive reclaim. >>> So maybe it's possible to add just aging functionality specific to >>> MGLRU? It'd be nice to know how you're going to use the aging, or why >> Due to debugfs not always mount, if we want to now lrugen's info, maybe >> nice to offer a memcg's node to show per memcg's lrugen info. >>> you want this version of eviction instead of what memory.reclaim does. > I think Yu's inquiry was about whether you will look at the lrugen Thanks to point that. > info from the memcg file for a production use case, or just for > debugging where you don't have debugfs for some reason. Because it's a Yes, for now use, just collect log from it, not have control logic. For future use, maybe we need to control a memcg's lru_gen anon seq reclaim. (just assume) > long term commitment to add the file.
OK, if I can offer a actually use case, I will send again
Thanks too much.
| |