Re: [PATCH 0/5] KVM: guest_memfd: bind backing memory to a NUMA node

[Gregory Price <gourry@gourry.net>]

On Wed, Sep 09, 2026 at 04:23:07PM -0700, Ackerley Tng wrote:
> Gregory Price <gourry@gourry.net> writes:
> 
> > in fact at that granularity, the desired node may not even have eligible
> > memory to host the task's memory.
> >
> 
> We have a similar problem where we wanted only guest memory to be
> charged a certain memcg. Currently guest_memfd memory is charge to
> mm->owner, which is the thread's parent, so doing the fallocate() in a
> thread wasn't good enough. The workaround was to have the fallocate()
> done in a separate process (fork) and have the child process's memcg be
> set to the desired memcg.
> 
> This workaround is kind of awkward, but could it technically work for
> NUMA allocations?
> 

That is a very clunky work-around, I'm not sure it's good to formalize
that kind of design as an expected user behavior.

Whatever the case, the issue of ineligible memory isn't resolved by
this.  A node may be 100% ZONE_MOVABLE, and later entirely unmapped -
literally no eligible memory for kernel allocations for the task itself.

> >
> > This was a consideration - although it has other limitations and larger
> > complexities associated with it.
> >
> > Where does the policy live for random fd's? (inode? address_space?)
> >
> 
> Off the top of my head the policy would be saved at gi->policy, where
> it's stored for mbind() now. fd+offset is just another way of
> referencing the offsets to set the policy.
>

It makes sense for anon use cases like this, but for some random file
where fbind() means "put unmapped page cache on node X" the story is
less clear.

> > How is a reclaimed inode's policy handled? (lost forever?)
> >
> > figured i'd start by reducing the scope to the narrowest and clearest
> > use-case, but I did expect to have the fbind() conversation.
> >
> > I'm open to it, but it seems like over-engineering.
> >
> > If you look at tmpfs / shmem, you'll see there is the option for a
> > default filesystem-wide mempolicy that can be plumbed, but i'm not sure
> > there's a real usecase for per-file mempolicies that isn't literally
> > guest_memfd.
> >
> 
> I see, can't think of other use-cases for per-file mempolicies either.
> 

The only thing i've considered is something like GPU wanting a file
faulted directly onto its node - but that's a mapped region, and that's
handled by existing semantics.

> >> May I know more about the use case behind this new feature?
> >>
> >
> > see above - confidential vm whose memory is quarantined to a particular
> > device, without placing that same burden on the host memory.
> >
> 
> Is lazy allocation a requirement for you? (as opposed to fallocate()-ing
> before the guest touches pages)
> 

Yes, because eventually some kind of overcommit will be desired. May as
well build it in from the start.

Looking forward to LPC :]

~Gregory