[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZV/HSFMmv3xwkNPL@memverge.com>
Date: Thu, 23 Nov 2023 16:42:32 -0500
From: Gregory Price <gregory.price@...verge.com>
To: Zhongkun He <hezhongkun.hzk@...edance.com>
Cc: Vinicius Petrucci <vpetrucci@...il.com>, akpm@...ux-foundation.org,
linux-mm@...r.kernel.org, linux-cxl@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
linux-api@...r.kernel.org, minchan@...nel.org,
dave.hansen@...ux.intel.com, x86@...nel.org,
Jonathan.Cameron@...wei.com, aneesh.kumar@...ux.ibm.com,
ying.huang@...el.com, dan.j.williams@...el.com, fvdl@...gle.com,
surenb@...gle.com, rientjes@...gle.com, hannes@...xchg.org,
mhocko@...e.com, Hasan.Maruf@....com, jgroves@...ron.com,
ravis.opensrc@...ron.com, sthanneeru@...ron.com,
emirakhur@...ron.com, vtavarespetr@...ron.com
Subject: Re: [RFC PATCH] mm/mbind: Introduce process_mbind() syscall for
external memory binding
On Fri, Nov 24, 2023 at 04:13:41PM +0800, Zhongkun He wrote:
>
> Per my understanding, the process_mbind() is implementable without
> many difficult challenges,
> since it is always protected by mm->mmap_lock. But task mempolicy does
> not acquire any lock
> in alloc_pages().
per-vma policies are protected by the mmap lock, while the task
mempolicy is protected by the task lock on replacement, and
task->mems_allowed (protected by task_lock).
There is an update in my refactor tickets that enforces the acquisition
of task_lock on mpol_set_nodemask, which prevents the need for
alloc_pages to do anything else. That's not present in this patch.
Basically mems_allowed deals with the majority of situations, and
mmap_lock deals with per-vma mempolicy changes and migrations.
~Gregory
Powered by blists - more mailing lists