Re: [RFC] mm: MADV_COLLAPSE semantics

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

 



On Thu 26-05-22 19:30:20, Matthew Wilcox wrote:
> On Wed, May 25, 2022 at 10:24:55AM +0200, Michal Hocko wrote:
> > I am not so sure about the global "never" policy, though. The global
> > policy controls _kernel_ driven THPs. As the request to collapse memory
> > comes from the userspace I do not think it should be limited by the
> > kernel policy. I also think it can be beneficial to implement userspace
> > based THP policies and exclude any kernel interference and that could be
> > achieved by global kernel "never" policy and implement the whole
> > functionality by process_madvise.
> 
> I'd prefer to see "never" mean "Don't run khugepaged" rather than "Do
> not create THPs".  If the app explicitly asks for a THP, I think it
> should get one, regardless of the sysadmin's will.
> 
> Death to tunables.  Can we just delete
> /sys/kernel/mm/transparent_hugepage/shmem_enabled entirely?

I do agree that our existing tunables are really complex. One more
reason to not bind the new sync and userspace driven collapsing
functionality to it by any means. Let's really not spread the headache
to the userspace as well.
-- 
Michal Hocko
SUSE Labs




[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