Re: [RFC PATCH 1/4] mm/mempolicy: Expose policy_nodemask() in include/linux/mempolicy.h

[David Hildenbrand]

On 16.06.25 13:02, Huang, Ying wrote:
> 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()).

How is the vmf used for that ("it uses the vmf only for ...")?

But yes, anything that relies on "thiscpu" and "thisnid" might be 
fault-specific as well (what I mentioned further below)


--
Cheers,

David / dhildenb