On Wed, Sep 09, 2026 at 04:23:07PM -0700, Ackerley Tng wrote: > Gregory Price <[email protected]> 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
