Gregory Price <[email protected]> writes: > On Fri, Sep 25, 2026 at 05:50:47PM -0700, Ackerley Tng wrote: >> + e.g. for tmpfs, >> + Use mount page size. >> + Respect mount size limits. >> + Use guest_memfd mpol and fall back to mount mpol. >> + Gregory, now you can set mpol upfront on a mount! [3]) > > I haven't had time to quite give this the read it deserves yet (have > been traveling this past week), but I think this mpol/mount issue can > be solved with a new dax driver (which maybe provides this provider > interface) without needing to involve numa policy at all. > > Essentially > > fd = open("/dev/cxl_dev", ...); /* backed by anondax driver */ > > then later when a fault on that fd happens, the driver provides an > anon-memory allocation that explicitly requests the node associated > with that device - as opposed to trying to jam this into mempolicy. > > If you're planning to be at LPC, happy to discuss this in person, but I > think this provider pattern is likely much cleaner without mempolicy at > all if you can just make the provider do that allocation path for you. >
Nice meeting you at LPC :) I agree with you, I don't mean to require some kind of mempolicy setup for every provider. IIUC you're saying the entire /dev/cxl_dev is some fixed NUMA node, any allocations from /dev/cxl_dev is from that NUMA node? In that case, if /dev/cxl_dev is used with guest_memfd, guest_memfd's configured mpol, as in kvm_gmem_set_policy [1], just can't apply then. /dev/cxl_dev fully controls where the memory is allocated. On traditional mounts like HugeTLBfs or tmpfs mounts where the mount config supports mpol definitions, we first apply guest_memfd's configured mpol, and fallback to the mount's policy if there was no configured mpol for guest_memfd. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/virt/kvm/guest_memfd.c#n400 > ~Gregory
