Re: [RFC] mm: MADV_COLLAPSE semantics

[Michal Hocko <mhocko@suse.com>]

On Tue 31-05-22 14:36:50, Zach O'Keefe wrote:
> Thanks everyone for your time and for the great discussion!
> 
> For the purposes of arriving at a decision, I've tried to outline the
> major points + my 2c below as:
> 
> 1. Breaking userland. AFAIK, if permitting MADV_COLLAPSE in "never"
> will break real, existing use cases, then linux's policy would
> necessitate that we don't do that. Is there a way we can reasonably
> determine this? An affirmative answer here makes this decision easy.

As pointed in other reply. Never doesn't really imply no THPs. At least
shmem doesn't obey that configuration and relies on the mount option
instead AFAIR.

[...]
> 3. Future uses of "never". Do we want to permit a policy where
> userspace *entirely* takes over THP allocation, and khugepaged and
> at-fault is disabled in the kernel? If yes, then then might as well
> permit "never" to allow that now. Personally, though, I can't imagine
> wanting to disable faulting-in THPs in places where we know data will
> be hot; but respecting "never" does back us into a corner if we ever
> go that route.

My experience tells me that usecases to take control into the userspace
grow rather than shrink. We have people asking for memory reclaim into
the userspace and I do not really see reasons why THPs would any
different.

If we ever really need a global THP kill switch to act on any types
of mappings then we would need to add a new knob because changing the
existing one would be hard without any regressions.
-- 
Michal Hocko
SUSE Labs