[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20231122133348.d27c09a90bce755dc1c0f251@linux-foundation.org>
Date: Wed, 22 Nov 2023 13:33:48 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Gregory Price <gourry.memverge@...il.com>
Cc: linux-mm@...ck.org, linux-doc@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
arnd@...db.de, tglx@...utronix.de, luto@...nel.org,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, mhocko@...nel.org, tj@...nel.org,
ying.huang@...el.com, Gregory Price <gregory.price@...verge.com>
Subject: Re: [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally
modifiable via syscall and procfs
On Wed, 22 Nov 2023 16:11:49 -0500 Gregory Price <gourry.memverge@...il.com> wrote:
> The patch set changes task->mempolicy to be modifiable by tasks other
> than just current.
>
> The ultimate goal is to make mempolicy more flexible and extensible,
> such as adding interleave weights (which may need to change at runtime
> due to hotplug events). Making mempolicy externally modifiable allows
> for userland daemons to make runtime performance adjustments to running
> tasks without that software needing to be made numa-aware.
Please add to this [0/N] a full description of the security aspect: who
can modify whose mempolicy, along with a full description of the
reasoning behind this decision.
> 3. Add external interfaces which allow for a task mempolicy to be
> modified by another task. This is implemented in 4 syscalls
> and a procfs interface:
> sys_set_task_mempolicy
> sys_get_task_mempolicy
> sys_set_task_mempolicy_home_node
> sys_task_mbind
> /proc/[pid]/mempolicy
Why is the procfs interface needed? Doesn't it simply duplicate the
syscall interface? Please update [0/N] with a description of this
decision.
> The new syscalls are the same as their current-task counterparts,
> except that they take a pid as an argument. The exception is
> task_mbind, which required a new struct due to the number of args.
>
> The /proc/pid/mempolicy re-uses the interface mpol_parse_str format
> to enable get/set of mempolicy via procsfs.
>
> mpol_parse_str format:
> <mode>[=<flags>][:<nodelist>]
>
> Example usage:
>
> echo "default" > /proc/pid/mempolicy
> echo "prefer=relative:0" > /proc/pid/mempolicy
> echo "interleave:0-3" > /proc/pid/mempolicy
What do we get when we read from this? Please add to changelog.
> Changing the mempolicy does not induce memory migrations via the
> procfs interface (which is the exact same behavior as set_mempolicy).
>
Powered by blists - more mailing lists