Message-ID: <06f602073cc65e4d3f1e61a59f432a9616c78fa8.camel@intel.com>
Date: Thu, 5 Jun 2025 17:53:46 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "ackerleytng@...gle.com" <ackerleytng@...gle.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
CC: "pvorel@...e.cz" <pvorel@...e.cz>, "palmer@...belt.com"
	<palmer@...belt.com>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"Miao, Jun" <jun.miao@...el.com>, "Shutemov, Kirill"
	<kirill.shutemov@...el.com>, "pdurrant@...zon.co.uk" <pdurrant@...zon.co.uk>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "nsaenz@...zon.es" <nsaenz@...zon.es>,
	"peterx@...hat.com" <peterx@...hat.com>, "keirf@...gle.com"
	<keirf@...gle.com>, "amoorthy@...gle.com" <amoorthy@...gle.com>,
	"quic_svaddagi@...cinc.com" <quic_svaddagi@...cinc.com>, "jack@...e.cz"
	<jack@...e.cz>, "vkuznets@...hat.com" <vkuznets@...hat.com>, "maz@...nel.org"
	<maz@...nel.org>, "mail@...iej.szmigiero.name" <mail@...iej.szmigiero.name>,
	"hughd@...gle.com" <hughd@...gle.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Wang, Wei W" <wei.w.wang@...el.com>,
	"tabba@...gle.com" <tabba@...gle.com>, "Wieczor-Retman, Maciej"
	<maciej.wieczor-retman@...el.com>, "Zhao, Yan Y" <yan.y.zhao@...el.com>,
	"ajones@...tanamicro.com" <ajones@...tanamicro.com>, "willy@...radead.org"
	<willy@...radead.org>, "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
	"quic_mnalajal@...cinc.com" <quic_mnalajal@...cinc.com>, "aik@....com"
	<aik@....com>, "usama.arif@...edance.com" <usama.arif@...edance.com>,
	"Hansen, Dave" <dave.hansen@...el.com>, "fvdl@...gle.com" <fvdl@...gle.com>,
	"rppt@...nel.org" <rppt@...nel.org>, "bfoster@...hat.com"
	<bfoster@...hat.com>, "quic_cvanscha@...cinc.com"
	<quic_cvanscha@...cinc.com>, "Du, Fan" <fan.du@...el.com>,
	"anthony.yznaga@...cle.com" <anthony.yznaga@...cle.com>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>, "anup@...infault.org"
	<anup@...infault.org>, "mic@...ikod.net" <mic@...ikod.net>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"quic_eberman@...cinc.com" <quic_eberman@...cinc.com>,
	"muchun.song@...ux.dev" <muchun.song@...ux.dev>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "Li, Zhiquan1" <zhiquan1.li@...el.com>,
	"rientjes@...gle.com" <rientjes@...gle.com>, "Aktas, Erdem"
	<erdemaktas@...gle.com>, "mpe@...erman.id.au" <mpe@...erman.id.au>,
	"david@...hat.com" <david@...hat.com>, "jgg@...pe.ca" <jgg@...pe.ca>,
	"steven.price@....com" <steven.price@....com>, "jhubbard@...dia.com"
	<jhubbard@...dia.com>, "Xu, Haibo1" <haibo1.xu@...el.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "jthoughton@...gle.com" <jthoughton@...gle.com>,
	"steven.sistare@...cle.com" <steven.sistare@...cle.com>,
	"quic_pheragu@...cinc.com" <quic_pheragu@...cinc.com>, "jarkko@...nel.org"
	<jarkko@...nel.org>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>, "Huang,
 Kai" <kai.huang@...el.com>, "shuah@...nel.org" <shuah@...nel.org>,
	"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>, "pankaj.gupta@....com"
	<pankaj.gupta@....com>, "Peng, Chao P" <chao.p.peng@...el.com>,
	"nikunj@....com" <nikunj@....com>, "Graf, Alexander" <graf@...zon.com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	"jroedel@...e.de" <jroedel@...e.de>, "suzuki.poulose@....com"
	<suzuki.poulose@....com>, "jgowans@...zon.com" <jgowans@...zon.com>, "Xu,
 Yilun" <yilun.xu@...el.com>, "liam.merwick@...cle.com"
	<liam.merwick@...cle.com>, "michael.roth@....com" <michael.roth@....com>,
	"quic_tsoni@...cinc.com" <quic_tsoni@...cinc.com>,
	"richard.weiyang@...il.com" <richard.weiyang@...il.com>, "Weiny, Ira"
	<ira.weiny@...el.com>, "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "Li,
 Xiaoyao" <xiaoyao.li@...el.com>, "qperret@...gle.com" <qperret@...gle.com>,
	"kent.overstreet@...ux.dev" <kent.overstreet@...ux.dev>,
	"dmatlack@...gle.com" <dmatlack@...gle.com>, "james.morse@....com"
	<james.morse@....com>, "brauner@...nel.org" <brauner@...nel.org>,
	"pgonda@...gle.com" <pgonda@...gle.com>, "quic_pderrin@...cinc.com"
	<quic_pderrin@...cinc.com>, "hch@...radead.org" <hch@...radead.org>,
	"will@...nel.org" <will@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"roypat@...zon.co.uk" <roypat@...zon.co.uk>
Subject: Re: [RFC PATCH v2 38/51] KVM: guest_memfd: Split allocator pages for
 guest_memfd use

On Thu, 2025-06-05 at 10:15 -0700, Ackerley Tng wrote:
> > > > > > > > Did you consider designing struct guestmem_allocator_operations
> > > > > > > > so that > > > > it > > could
> > > > > > > > encapsulate the special logic for both the existing and new
> > > > > > > > allocators?
> > > > 
> > > > I did, yes. I believe it is definitely possible to make standard 4K
> > > > pages become another allocator too.
> > > > 
> > > > I would love to clean this up. Not sure if that will be a new series
> > > > after this one, or part of this one though.

Usually new work should handle the refactor first, then build on top of it. The
code today bolts on a new thing in a dirty way leaving cleanup.

Towards also expedient reviewability, a better order could be:
1. Add allocator callbacks one at a time (or in whatever granularity is
possible), moving 4k allocator to callbacks at the same time. Basically a code
move. Don't factor out common code between the planned allocators. Will be dirt
simple to review.
2. Introduce changes to hugelbfs, explaining why each will be used by guestmemfd
3. Add hugetlbsfs/1GB custom allocator to guestmemfd code, a callback at a time.
Have any necessary factoring out of 4k page allocator bits out of the callback
implementation come in a separate preceding patch. Explain the commonality.

What do you think?

Also, for (2) do you think you could move some of these pure cleanup patches out
of the series to go up ahead of time? And for any hugetlb changes that 1GB
guestmemfd depends on, explain why in the log? I'm not clear what is required
and what is opportunistic cleanup.


> > > > 
> > > > > > > > If it
> > > > > > > > didn't work well, could we expect that a next allocator would
> > > > > > > > actually > > > > fit
> > > > > > > > struct guestmem_allocator_operations?
> > > > > > > > 
> > > > 
> > > > This was definitely designed to support allocators beyond
> > > > guestmem_hugetlb, though I won't promise that it will be a perfect fit
> > > > for future allocators. This is internal to the kernel and this interface
> > > > can be updated for future allocators though.

Makes sense. This was probing on whether the interface didn't fit the 4k
allocator. It makes sense to have the interface target the existing 2
allocators, and no future ideas.

Powered by blists - more mailing lists