Re: [RFC v2] mm: Multi-Gen LRU: fix use mm/page_idle/bitmap

[David Rientjes <rientjes@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

On Thu, 21 Dec 2023, Yu Zhao wrote:

> > Thanks for replyting.
> >
> > On Fri, Dec 22, 2023 at 07:16 AM Yuanchu Xie wrote:
> > > How does the shared memory get charged to the cgroups?
> > > Does it all go to cgroup A or B exclusively, or do some pages get
> > > charged to each one?
> >
> > Some pages get charged to cgroup A, and the other get charged to cgroup B.
> 
> Just a side note:
> We can potentially "fix" this, but it doesn't mean this is a good
> practice. In fact, I think this is an anti-pattern to memcgs:
> resources should be preferably isolated between memcgs, or if a
> resource has to be shared between memcgs, it should be charged in a
> predetermined way, not randomly to one of the memcgs sharing it.
> 

Very interesting thread, a few questions for Henry to understand the 
situation better:

 - is the lack of predeterministic charging a problem for you?  Are you
   initially faulting it in a manner that charges it to the "right" memcg
   and the refault of it after periodic reclaim can causing the charge to
   appear "randomly," i.e. to whichever process happened to access it 
   next?

 - are pages ever shared between different memcg hierarchies?  You 
   mentioned sharing between processes in A and A/B, but I'm wondering
   if there is sharing between two different memcg hierarchies where root
   is the only common ancestor?

 - do you anticipate a shorter scan period at some point?  Proactively
   reclaiming all memory colder than one hour is a long time :)  Are you
   concerned at all about the cost of doing your current idle bit 
   harvesting approach becoming too expensive if you significantly reduce
   the scan period?

 - is proactive reclaim being driven by writing to memory.reclaim, by
   enforcing a smaller memory.high, or something else?

Looking forward to learning more about your particular issue.