lkml.org 
[lkml]   [2022]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH mmotm] mempolicy: mbind_range() set_policy() after vma_merge()
On Wed, 9 Mar 2022, Liam Howlett wrote:
> * Vlastimil Babka <vbabka@suse.cz> [220309 07:41]:
> > On 3/8/22 22:32, Hugh Dickins wrote:
> >
> > > Does that help?
>
> I think so. You want to set the mpol the same across the vma because we
> are specifically calling mbind, but it isn't necessary because the mpol
> is equivalent but not the same mpol?

I did not understand that logic, so cannot confirm it.

The crucial point, as I see it, is that a call to shmem_set_policy() was
needed in many cases, but had been "optimized away" by the mpol_equal test.

> I guess I have the same question
> as Vlastimil brought up - why does tmpfs need this?

One way of answering would be: because tmpfs is used to back SysV SHM,
and "man 2 mbind" has a paragraph on the subject of mbind on a shared
memory region created using the shmget(2) system call.

Or you could look in Documentation/admin-guide/mm/numa_memory_policy.rst,
section on "Shared Policy". (But it's a surprise to me to see how that
makes no mention of tmpfs itself: it's as if it's just an accident that
this is how NUMA mempolicy is applied to mappings of tmpfs files.)

An important comment from ChangeLog-2.6.7 when mm/mempolicy.c came in:
For shmfs/tmpfs/hugetlbfs shared memory the policy is shared between
all users and remembered even when nobody has memory mapped.

(But although hugetlbfs support was intended in the original RFC to lkml,
it was never implemented in the tree, despite appearances: a patch I did
not send this time, but eventually will, removes the appearance of shared
mempolicy on hugetlbfs.)

Hugh

\
 
 \ /
  Last update: 2022-03-11 10:33    [W:0.146 / U:1.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site