Re: [RFC] mm: MADV_COLLAPSE semantics

[Yang Shi <shy828301@gmail.com>]

On Tue, May 31, 2022 at 2:37 PM Zach O'Keefe <zokeefe@google.com> 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:

Thanks for summing up the discussion.

>
> 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.

I don't have an affirmative answer. It depends on the users'
expectations. Some users may expect there won't be any THP allocation
in "never" mode even though it is requested by the users. AFAICT some
sys admins may expect so since they may manage machines which may run
untrusted software. So allowing MADV_COLLAPSE in "never" doesn't break
any workload, but may break some expectations.

>
> 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?

I do not have strong objections, and I think Michal's point and yours
do make some sense for some usecases. A simple way is to allow
MADV_COLLAPSE in "never" mode, then see whether there will be any
complaints.

>
> Thanks again for your time,
> Zach