mempolicy ref-counting question

mempolicy ref-counting question

[Rasmus Villemoes]

I'm trying to understand why "git grep mpol_get" doesn't give more hits
than it does. Two of the users (kernel/sched/debug.c and
fs/proc/task_mmu.c) seem to only hold the extra reference while writing
to a seq_file. That leaves just three actual users.

In particular, I'm wondering why __split_vma (and copy_vma) use
vma_dup_policy instead of simply getting an extra reference on the
old. I see there's some cpuset_being_rebound dance in mpol_dup, but I
don't understand why that's needed: In __split_vma, we're holding
mmap_sem, so either update_tasks_nodemask has already visited this mm
via mpol_rebind_mm (which also takes the mmap_sem), so the old vma is
already rebound, or the mpol_rebind_mm call will come later and rebind
the mempolicy of both the old and new vma - why would it matter that the
new vma's policy is rebound immediately?

I'd appreciate it if someone could enlighten me (I'm probably
missing something obvious).

Rasmus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mempolicy ref-counting question

[Oleg Nesterov]

I can't answer, so let me add cc's. I never understood mempolicy.c and
I forgot everything I learned when I added vma_dup_policy ;) and that
patch didn't change this logic as you can see.

All I can say is that it _seems_ to me you are right, split_vma() could
use mpol_get()...

At least mbind_range() lools suboptimal. split_vma() creates a copy, and
right after that vma_replace_policy() does another mpol_dup().

On 04/21, Rasmus Villemoes wrote:
>
> I'm trying to understand why "git grep mpol_get" doesn't give more hits
> than it does. Two of the users (kernel/sched/debug.c and
> fs/proc/task_mmu.c) seem to only hold the extra reference while writing
> to a seq_file. That leaves just three actual users.
>
> In particular, I'm wondering why __split_vma (and copy_vma) use
> vma_dup_policy instead of simply getting an extra reference on the
> old. I see there's some cpuset_being_rebound dance in mpol_dup, but I
> don't understand why that's needed: In __split_vma, we're holding
> mmap_sem, so either update_tasks_nodemask has already visited this mm
> via mpol_rebind_mm (which also takes the mmap_sem), so the old vma is
> already rebound, or the mpol_rebind_mm call will come later and rebind
> the mempolicy of both the old and new vma - why would it matter that the
> new vma's policy is rebound immediately?
>
> I'd appreciate it if someone could enlighten me (I'm probably
> missing something obvious).
>
> Rasmus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>