linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yisheng Xie <xieyisheng1@huawei.com>
To: Christopher Lameter <cl@linux.com>, Vlastimil Babka <vbabka@suse.cz>
Cc: akpm@linux-foundation.org, mhocko@suse.com, mingo@kernel.org,
	rientjes@google.com, n-horiguchi@ah.jp.nec.com,
	salls@cs.ucsb.edu, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, tanxiaojun@huawei.com,
	linux-api@vger.kernel.org, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH RFC v2 4/4] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
Date: Wed, 8 Nov 2017 09:38:36 +0800	[thread overview]
Message-ID: <4b08f1e9-5449-6ea2-e7da-65fe5f678683@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1711070948410.19176@nuc-kabylake>

Hi Christopher,

On 2017/11/7 23:55, Christopher Lameter wrote:
> On Tue, 7 Nov 2017, Vlastimil Babka wrote:
> 
>>> Migrate pages moves the pages of a single process there is no TARGET
>>> process.
>>
>> migrate_pages(2) takes a pid argument
>>
>> "migrate_pages()  attempts  to  move all pages of the process pid that
>> are in memory nodes old_nodes to the memory nodes in new_nodes. "
> 
> Ok missed that. Most use cases here are on the current process.

Yeah, so most case current process is the same as target process.
But maybe I still miss someting, see below:

> 
> Fundamentally a process can have shared pages outside of the cpuset that
> a process is restricted to. Thus I would think that migration to any of
> the allowed nodes of the current process that is calling migrate pages
> is ok. The caller wants this and the caller has a right to allocate on
> these nodes. It would be strange if migrate_pages would allow allocation
> outside of the current cpuset.
> 
>>> Thus thehe *target* nodes need to be a subset of the current cpu set.
> 
> And therefore the above still holds.

Another case is current process is *not* the same as target process, and
when current process try to migrate pages of target process from old_nodes
to new_nodes, the new_nodes should be a subset of target process cpuset.
CAP_SYS_NICE will insure that current process have the privilege, and will
not overwrite the restriction of target process cpuset.

However, for the current cpuset restriction, as manpage says :
  EINVAL... Or, _none_ of the node IDs specified by new_nodes are
  on-line and allowed by the process's current cpuset context, or none of
  the specified nodes contain memory.

So for current cpuset restriction, an intersection check should be enough
instead of subset? And it will also make sure migrate_pages will not
allocate pages outside of the current cpuset.

> 
> .
> 

--
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>

  reply	other threads:[~2017-11-08  1:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 10:14 [PATCH RFC v2 0/4] some fixes and clean up for mempolicy Yisheng Xie
2017-10-27 10:14 ` [PATCH RFC v2 1/4] mm/mempolicy: Fix get_nodes() mask miscalculation Yisheng Xie
2017-10-31  8:34   ` Vlastimil Babka
2017-11-01  9:37     ` Yisheng Xie
2017-10-27 10:14 ` [PATCH RFC v2 2/4] mm/mempolicy: remove redundant check in get_nodes Yisheng Xie
2017-10-31  8:55   ` Vlastimil Babka
2017-10-27 10:14 ` [PATCH RFC v2 3/4] mm/mempolicy: fix the check of nodemask from user Yisheng Xie
2017-10-31  9:30   ` Vlastimil Babka
2017-10-31 11:01     ` Yisheng Xie
2017-10-31 11:28       ` Vlastimil Babka
2017-10-27 10:14 ` [PATCH RFC v2 4/4] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages Yisheng Xie
2017-10-31  9:46   ` Vlastimil Babka
2017-11-06  1:31     ` Yisheng Xie
2017-11-06  7:39       ` Vlastimil Babka
2017-11-06 15:29         ` Christopher Lameter
2017-11-07 11:23           ` Yisheng Xie
2017-11-07 14:54             ` Christopher Lameter
2017-11-07 15:05               ` Vlastimil Babka
2017-11-07 15:55                 ` Christopher Lameter
2017-11-08  1:38                   ` Yisheng Xie [this message]
2017-11-08 15:02                     ` Christopher Lameter
2017-11-09 10:54                       ` Yisheng Xie
2017-11-09 15:46                         ` Christopher Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b08f1e9-5449-6ea2-e7da-65fe5f678683@huawei.com \
    --to=xieyisheng1@huawei.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=rientjes@google.com \
    --cc=salls@cs.ucsb.edu \
    --cc=tanxiaojun@huawei.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox