linux-kernel - Re: [PATCH] mm: split thp synchronously on MADV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e55d1f78-46c2-9ced-d7ad-c6deba4cb7b8@google.com>
Date:   Mon, 24 Jan 2022 10:48:55 -0800 (PST)
From:   David Rientjes <rientjes@...gle.com>
To:     Peter Xu <peterx@...hat.com>, Zach O'Keefe <zokeefe@...gle.com>,
        SeongJae Park <sj@...nel.org>
cc:     Shakeel Butt <shakeelb@...gle.com>,
        David Hildenbrand <david@...hat.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Yang Shi <shy828301@...il.com>, Zi Yan <ziy@...dia.com>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: split thp synchronously on MADV_DONTNEED

On Fri, 26 Nov 2021, Peter Xu wrote:

> Some side notes: I digged out the old MADV_COLLAPSE proposal right after I
> thought about MADV_SPLIT (or any of its variance):
> 
> https://lore.kernel.org/all/d098c392-273a-36a4-1a29-59731cdf5d3d@google.com/
> 
> My memory was that there's some issue to be solved so that was blocked, however
> when I read the thread it sounds like the list was mostly reaching a consensus
> on considering MADV_COLLAPSE being beneficial.  Still copying DavidR in case I
> missed something important.
> 
> If we think MADV_COLLAPSE can help to implement an userspace (and more
> importantly, data-aware) khugepaged, then MADV_SPLIT can be the other side of
> kcompactd, perhaps.
> 
> That's probably a bit off topic of this specific discussion on the specific use
> case, but so far it seems all reasonable and discussable.
> 

Hi Peter,

Providing a (late) update since we now have some better traction on this, 
I think we'll be ready to post an RFC soon that introduces MADV_COLLAPSE.  
The work is being driven by Zach, now cc'd.

Let's also include SeongJae Park <sj@...nel.org> as well and keep him in 
the loop since DAMON could easily be extended with a DAMOS_COLLAPSE action 
to use MADV_COLLAPSE for hot regions of memory.

Idea for initial approach:

 - MADV_COLLAPSE core code based on the proposal you cite above for anon 
   memory as the inaugural support, collapse memory into thp in process 
   context

 - Batching support to collapse ranges of memory into multiple THP

 - Wire this up for madvise(2) (and process_madvise(2))

 - Enlightenment for file-backed thp

I think Zach's RFC will cover the first three, it could be debated if the 
initial patch series *must* support file-backed thp.  We'll see based on 
the feedback to the RFC.

There's also an extension where MADV_COLLAPSE could be potentially useful 
for hugetlb backed memory.  We have another effort underway that we've 
been talking with Mike Kravetz about that allows hugetlb memory to be 
mapped at multiple levels of the page tables.  There are several use cases 
but one of the driving factors is the performance of post-copy live 
migration; in this case, you'd be able to send smaller sized pages over 
the wire rather than, say, a 1GB gigantic page.

In this case, MADV_COLLAPSE could be useful to map smaller pages by 
a larger page table entry before all of the smaller pages have been live 
migrated.

That said, we have not invested time into an MADV_SPLIT yet.

Do you (or anybody else) have concerns about this approach?  Ideas for 
extensions?

Thanks!