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
