Re: [RFC] mm: MADV_COLLAPSE semantics

[Yang Shi <shy828301@gmail.com>]

On Thu, May 26, 2022 at 11:30 AM Matthew Wilcox <willy@infradead.org> 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.

If we want to decouple THP allocation and khugepaged, maybe a
dedicated switch for khugepaged? Just like /sys/kernel/mm/ksm/run? Or
I should have not proposed a new knob :-)

>
> Death to tunables.  Can we just delete
> /sys/kernel/mm/transparent_hugepage/shmem_enabled entirely?

It is used to control non-mount shm objects, for example, memfd, sys v
shm. The tmpfs has mount options that control huge page eligibility.

Consolidate to /sys/kernel/mm/transparent_hugepage/enabled? Maybe, but
shmem_enabled has a couple of special modes:
- within_size: only allocate huge pages if the page will be fully within i_size
- force: enable THP for all mount tmpfs and non-mount shm
- deny: do opposite of force

force and deny are basically used for debugging purposes.

BTW, currently file THP (readonly fs) is actually controlled by
/sys/kernel/mm/transparent_hugepage/enabled since it just can be
created by khugepaged for now.