Re: [f2fs-dev] [PATCH kvm-next V11 6/7] KVM: guest_memfd: Enforce NUMA mempolicy using shared policy

Gregory Price
2025-10-16T14:17:31Z

On Wed, Oct 15, 2025 at 03:48:38PM -0700, Sean Christopherson wrote:
> On Wed, Oct 15, 2025, Gregory Price wrote:
> > why is __kvm_gmem_get_policy using
> > mpol_shared_policy_lookup()
> > instead of
> > get_vma_policy()
>
> With the disclaimer that I haven't followed the gory details of this series super
> closely, my understanding is...
>
> Because the VMA is a means to an end, and we want the policy to persist even if
> the VMA goes away.
>

Ah, you know, now that i've taken a close look, I can see that you've
essentially modeled this after ipc/shm.c | mm/shmem.c pattern.

What's had me scratching my chin is that shm/shmem already has a
mempolicy pattern which ends up using folio_alloc_mpol() where the
relationship is

tmpfs: sb_info->mpol = default set by user
create_file: inode inherits copy of sb_info->mpol
fault: mpol = shmem_get_pgoff_policy(info, index, order, &ilx);
folio = folio_alloc_mpol(gfp, order, mpol, ilx, numa_node_id())

So this inode mempolicy in guest_memfd is really acting more as a the
filesystem-default mempolicy, which you want to survive even if userland
never maps the memory/unmaps the memory.

So the relationship is more like

guest_memfd -> creates fd/inode <- copies task mempolicy (if set)
vm: allocates memory via filemap_get_folio_mpol()
userland mmap(fd):
creates new inode<->vma mapping
vma->mpol = kvm_gmem_get_policy()
calls to set/get_policy/mbind go through kvm_gmem

This makes sense, sorry for the noise. Have been tearing apart
mempolicy lately and I'm disliking the general odor coming off
it as a whole. I had been poking at adding mempolicy support to
filemap and you got there first. Overall I think there are still
other problems with mempolicy, but this all looks fine as-is.

~Gregory