Re: [RFC] mm: MADV_COLLAPSE semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 25, 2022 at 1:24 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
> On Mon 23-05-22 17:18:32, Zach O'Keefe wrote:
> [...]
> > Idea: MADV_COLLAPSE should respect VM_NOHUGEPAGE and "never" THP mode,
> > but otherwise would attempt to collapse.
>
> I do agree that {process_}madvise should fail on VM_NOHUGEPAGE. The
> process has explicitly noted that THP shouldn't be used on such a VMA
> and seeing THP could be observed as not complying with that contract.
>
> 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 respect "never" for now since it is typically used to
disable THP globally even though the mappings are madvised
(MADV_HUGEPAGE). IMHO I treat MADV_COLLAPSE as weaker MADV_HUGEPAGE
(take effect for non-madvised mappings but not flip VM_NOHUGEPAGE) +
best-effort synchronous THP collapse.

We could lift the restriction in the future if it turns out non
respecting "never" is more useful.

> --
> Michal Hocko
> SUSE Labs




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux