From: Michal Hocko <mhocko@suse.com>
To: Zach O'Keefe <zokeefe@google.com>
Cc: 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>,
Yang Shi <shy828301@gmail.com>,
linux-mm@kvack.org, 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: Wed, 25 May 2022 10:24:55 +0200 [thread overview]
Message-ID: <Yo3n1/cTrmkLy5tV@dhcp22.suse.cz> (raw)
In-Reply-To: <CAAa6QmQxay1_=Pmt8oCX2-Va18t44FV-Vs-WsQt_6+qBks4nZA@mail.gmail.com>
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.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-05-25 8:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 0:18 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 [this message]
2022-05-25 17:32 ` Yang Shi
2022-05-25 18:09 ` Zach O'Keefe
2022-05-26 7:12 ` Michal Hocko
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=Yo3n1/cTrmkLy5tV@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox