Re: [RFC] mm: MADV_COLLAPSE semantics

["Zach O'Keefe" <zokeefe@google.com>]

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.

2. Current uses of "never" a.k.a dev/debug. If (1) is false, then
we've asserted that *currently* "never" is only used for
development/debugging. During development of MADV_COLLAPSE, I found it
necessary to disable khugepaged via a new debugfs tunable to prevent
khugepaged collapsing memory before MADV_COLLAPSE could act. If
MADV_COLLAPSE wasn't tied to "never", it's one less debugfs tunable
we'd need. OTOH, I can still see the benefit, during debugging, of a
master "no THPs" switch. If we think we'll ever want that master
switch, then let's just keep "never" as said switch.

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.

4. Flexibility / separation of concerns:  All else being equal,
decoupling user MADV_COLLAPSE from kernel THP sysfs controls is more
flexible and consistent with the rest of MADV_COLLAPSE semantics.

If that's roughly accurate, and in lieu of any other critical points,
if we can determine (1),  then I'd prefer "never" to be tied to kernel
decisions, not userspace. Any strong objections?

Thanks again for your time,
Zach