Hi David, Thanks for the review. On 2/12/2025 3:33 PM, David Hildenbrand wrote: > On 10.02.25 07:32, Shivank Garg wrote: >> From: Shivansh Dhiman <shivansh.dhiman@xxxxxxx> >> >> Add NUMA mempolicy support to the filemap allocation path by introducing >> new APIs that take a mempolicy argument: >> - filemap_grab_folio_mpol() >> - filemap_alloc_folio_mpol() >> - __filemap_get_folio_mpol() >> >> These APIs allow callers to specify a NUMA policy during page cache >> allocations, enabling fine-grained control over memory placement. This is >> particularly needed by KVM when using guest-memfd memory backends, where >> the guest memory needs to be allocated according to the NUMA policy >> specified by VMM. >> > > shmem handles this using custom shmem_alloc_folio()->folio_alloc_mpol(). > > I'm curious, is there > > (1) A way to make shmem also use this new API? > (2) Handle it in guest_memfd manually, like shmem does? (1) As you noted later, shmem has unique requirements due to handling swapin. It does considerable open-coding. Initially, I was considering simplifying the shmem but it was not possible due to above constraints. One option would be to add shmem's special cases in the filemap and check for themusing shmem_mapping()? But, I don't understand the shmem internals well enough to determine if it is feasible. (2) I considered handling it manually in guest_memfd like shmem does, but this would lead to code duplication and more open-coding in guest_memfd. The current approach seems cleaner. > Two tabs indent on second parameter line, please. > .. > > This should go below the variable declaration. (and indentation on second parameter line should align with the first parameter) > .. > "The mempolicy to apply when allocating a new folio." ? > I'll address all the formatting and documentation issues in next posting. > > For guest_memfd, where pages are un-movable and un-swappable, the memory policy will never change later. > > shmem seems to handle the swap-in case, because it keeps care of allocating pages in that case itself. > > For ordinary pagecache pages (movable), page migration would likely not be aware of the specified mpol; I assume the same applies to shmem? > > alloc_migration_target() seems to prefer the current nid (nid = folio_nid(src)), but apart from that, does not lookup any mempolicy. Page migration does handle the NUMA mempolicy using mtc (struct migration_target_control *) which takes node ID input and allocates on the "preferred" node id. The target node in migrate_misplaced_folio() is obtained using get_vma_policy(), so the per-VMA policy handles proper node placement for mapped pages. It use current nid (folio_nid(src)) only if NUMA_NO_NODE is passed. mempolicy.c provides the alloc_migration_target_by_mpol() that allocates according to NUMA mempolicy, which is used by do_mbind(). > > compaction likely handles this by comapcting within a node/zone. > > Maybe migration to the right target node on misplacement is handled on a higher level lagter (numa hinting faults -> migrate_misplaced_folio). Likely at least for anon memory, not sure about unmapped shmem. Yes. Thanks, Shivank
