Re: [PATCH v2 00/12] mm: userspace hugepage collapse

From: Peter Xu <peterx@redhat.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>,
	Michal Hocko <mhocko@suse.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	SeongJae Park <sj@kernel.org>, Song Liu <songliubraving@fb.com>,
	Vlastimil Babka <vbabka@suse.cz>, Yang Shi <shy828301@gmail.com>,
	Zi Yan <ziy@nvidia.com>,
	linux-mm@kvack.org, Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Chris Kennelly <ckennelly@google.com>,
	Chris Zankel <chris@zankel.net>, Helge Deller <deller@gmx.de>,
	Hugh Dickins <hughd@google.com>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Jens Axboe <axboe@kernel.dk>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Matt Turner <mattst88@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Minchan Kim <minchan@kernel.org>,
	Patrick Xia <patrickx@google.com>,
	Pavel Begunkov <asml.silence@gmail.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: [PATCH v2 00/12] mm: userspace hugepage collapse
Date: Thu, 14 Apr 2022 20:04:44 -0400	[thread overview]
Message-ID: <Yli2nLz/agg4+ZIK@xz-m1.local> (raw)
In-Reply-To: <20220414180612.3844426-1-zokeefe@google.com>

Hi, Zach,

On Thu, Apr 14, 2022 at 11:06:00AM -0700, Zach O'Keefe wrote:
> process_madvise(2)
> 
> 	Performs a synchronous collapse of the native pages
> 	mapped by the list of iovecs into transparent hugepages.
> 
> 	Allocation semantics are the same as khugepaged, and depend on
> 	(1) the active sysfs settings
> 	/sys/kernel/mm/transparent_hugepage/enabled and
> 	/sys/kernel/mm/transparent_hugepage/khugepaged/defrag, and (2)
> 	the VMA flags of the memory range being collapsed.
> 
> 	Collapse eligibility criteria differs from khugepaged in that
> 	the sysfs files
> 	/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_[none|swap|shared]
> 	are ignored.

The userspace khugepaged idea definitely makes sense to me, though I'm
curious how the line is drown on the different behaviors here by explicitly
ignoring the max_ptes_* entries.

Let's assume the initiative is to duplicate a more data-aware khugepaged in
the userspace, then IMHO it makes more sense to start with all the policies
that applies to khugepaged already, including max_pte_*.

I can understand the willingness to provide even stronger semantics here
than khugepaged since the userspace could have very clear knowledge of how
to provision the memories (better than a kernel scanner).  It's just that
IMHO it could be slightly confusing if the new interface only partially
apply the khugepaged rules.

No strong opinion here.  It could already been a trade-off after the
discussion from the RFC with Michal which I read..  Just curious about how
you made that design decision so feel free to read it as a pure question.

Thanks,

-- 
Peter Xu