Re: [RFC] Hugepage collapse in process context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 24 Feb 2021, Alex Shi wrote:

> > Agreed, and happy to see that there's a general consensus for the 
> > direction.  Benefit of a new madvise mode is that it can be used for 
> > madvise() as well if you are interested in only a single range of your own 
> > memory and then it doesn't need to reconcile with any of the already 
> > overloaded semantics of MADV_HUGEPAGE.
> 
> It's a good idea to let process deal with its own THP policy.
> but current applications will miss the benefit w/o changes, and change is
> expensive for end users. So except this work, may a per memcg collapse benefit
> apps and free for them, we often deploy apps in cgroups on server now.
> 

Hi Alex,

I'm not sure that I understand: this MADV_COLLAPSE would be possible for 
process_madvise() as well and by passing a vectored set of ranges so a 
process can do this on behalf of other processes (it's the only way that 
we could theoretically move khugepaged to userspace, although that's not 
an explicit end goal).

How would you see this working with memcg involved?  I had thought this 
was entirely orthogonal to any cgroup.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux