All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>,
	Alex Shi <alex.shi@linux.alibaba.com>,
	David Hildenbrand <david@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	Peter Xu <peterx@redhat.com>, Song Liu <songliubraving@fb.com>,
	Linux MM <linux-mm@kvack.org>,
	Rongwei Wang <rongwei.wang@linux.alibaba.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Hugh Dickins <hughd@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Minchan Kim <minchan@kernel.org>, SeongJae Park <sj@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [RFC] mm: MADV_COLLAPSE semantics
Date: Thu, 26 May 2022 09:12:17 +0200	[thread overview]
Message-ID: <Yo8oUUIG1T9t6sl0@dhcp22.suse.cz> (raw)
In-Reply-To: <CAHbLzkpeK8S0rHePZU_OJ_o8tBc0chUoj06PMkz_q0j8uiYj_A@mail.gmail.com>

On Wed 25-05-22 10:32:44, Yang Shi wrote:
> On Wed, May 25, 2022 at 1:24 AM Michal Hocko <mhocko@suse.com> 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.

MADV_HUGEPAGE is a way to tell the kernel what and how to do in future
time by the kernel.  MADV_COLLAPSE is a way tell what the userspace want
at the moment of the call. So I do not really think they are directly
related in any way except they somehow control THP.

The primary question here is whether we want to support usecases which
want to completely rule out THP handling by the kernel and only rely on
the userspace. If yes, I do not see other way than using never global
policy and rely on MADV_COLLAPSE from the userspace. Or am I missing
something?

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

I do not think we can change the behavior in the future without risking
regressions.
-- 
Michal Hocko
SUSE Labs


  parent reply	other threads:[~2022-05-26  7:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  0:18 [RFC] mm: MADV_COLLAPSE semantics Zach O'Keefe
2022-05-24 13:26 ` Peter Xu
2022-05-24 17:08   ` Zach O'Keefe
2022-05-24 20:02 ` Yang Shi
2022-05-25  8:24 ` Michal Hocko
2022-05-25 17:32   ` Yang Shi
2022-05-25 18:09     ` Zach O'Keefe
2022-05-26  7:12     ` Michal Hocko [this message]
2022-05-26 17:39       ` Yang Shi
2022-05-27  9:46         ` Michal Hocko
2022-05-31 23:47           ` Yang Shi
2022-06-01  9:50             ` Michal Hocko
2022-06-01 17:25               ` Yang Shi
2022-06-02  6:55                 ` Michal Hocko
2022-06-02 16:43                   ` Yang Shi
2022-06-03 13:26                     ` Zach O'Keefe
2022-06-03 13:33                       ` Zach O'Keefe
2022-05-26 18:30   ` Matthew Wilcox
2022-05-27  8:56     ` Michal Hocko
2022-05-27 18:09     ` Yang Shi
2022-05-31 21:36       ` Zach O'Keefe
2022-05-31 23:52         ` Yang Shi
2022-06-01  9:57         ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yo8oUUIG1T9t6sl0@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=aarcange@redhat.com \
    --cc=alex.shi@linux.alibaba.com \
    --cc=axelrasmussen@google.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterx@redhat.com \
    --cc=rientjes@google.com \
    --cc=rongwei.wang@linux.alibaba.com \
    --cc=shy828301@gmail.com \
    --cc=sj@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=willy@infradead.org \
    --cc=zokeefe@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.