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

[David Hildenbrand]

On 16.06.25 16:16, Bijan Tabatabai wrote:
> On Mon, Jun 16, 2025 at 4:46 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
> > 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:
> [...]
> > Hi,
> >
> > > 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.
>
> Sorry, I think I misunderstood you before. You are right, we should
> consider the VMA policy before using the task policy. I will do this
> in the next revision.
>
> > > 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.
> >
> > Which, you also have during the rmap walk.
>
> There is another subtle dependency in get_vma_policy.
> It first checks if a VMA policy exists, and if it doesn't, it uses the
> task policy of the current task, which doesn't make sense when called
> by a kdamond thread.

Indeed, anything that depends on current task / nid / cpu might require 
care.

--
Cheers,

David / dhildenb