David Hildenbrand <david@xxxxxxxxxx> writes: > On 13.06.25 18:33, Bijan Tabatabai wrote: >> On Fri, Jun 13, 2025 at 8:45 AM David Hildenbrand <david@xxxxxxxxxx> wrote: >>> >>> On 12.06.25 20:13, Bijan Tabatabai wrote: >>>> From: Bijan Tabatabai <bijantabatab@xxxxxxxxxx> >>>> [snip] >> I did not use get_vma_policy or mpol_misplaced, which I believe is >> the >> closest function that exists for what I want in this patch, because >> those functions > > I think what you mean is, that you are performing an rmap walk. But > there, you do have a VMA + MM available (stable). > >> seem to assume they are called inside of the task that the folio/vma >> is mapped to. > > But, we do have a VMA at hand, so why would we want to ignore any set > policy? (I think VMA policies so far only apply to shmem, but still). > > I really think you want to use get_vma_policy() instead of the task policy. > > >> More specifically, mpol_misplaced assumes it is being called within a >> page fault. >> This doesn't work for us, because we call it inside of a kdamond process. > > Right. > > But it uses the vmf only for ... > > 1) Obtaining the VMA > 2) Sanity-checking that the ptlock is held. 3) update NUMA balancing per-folio cpupid state (via should_numa_migrate_memory()). This needs to be called by the NUMA page fault handler. > Which, you also have during the rmap walk. > [snip] --- Best Regards, Huang, Ying
