From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752654AbdKHPCk (ORCPT <rfc822;w@1wt.eu>);
        Wed, 8 Nov 2017 10:02:40 -0500
Received: from resqmta-ch2-12v.sys.comcast.net ([69.252.207.44]:37218 "EHLO
        resqmta-ch2-12v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1751716AbdKHPCj (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 8 Nov 2017 10:02:39 -0500
Date: Wed, 8 Nov 2017 09:02:36 -0600 (CST)
From: Christopher Lameter <cl@linux.com>
X-X-Sender: cl@nuc-kabylake
To: Yisheng Xie <xieyisheng1@huawei.com>
cc: Vlastimil Babka <vbabka@suse.cz>, 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
In-Reply-To: <4b08f1e9-5449-6ea2-e7da-65fe5f678683@huawei.com>
Message-ID: <alpine.DEB.2.20.1711080900050.6161@nuc-kabylake>
References: <1509099265-30868-1-git-send-email-xieyisheng1@huawei.com> <1509099265-30868-5-git-send-email-xieyisheng1@huawei.com> <dccbeccc-4155-94a8-0e67-b7c28238896d@suse.cz> <bc57f574-92f2-0b69-4717-a1ec7170387c@huawei.com> <d774ecf6-5e7b-e185-85a0-27bf2bcacfb4@suse.cz>
 <alpine.DEB.2.20.1711060926001.9015@nuc-kabylake> <a4f1212f-3903-abbc-772a-1ddee6f7f98b@huawei.com> <alpine.DEB.2.20.1711070851560.18776@nuc-kabylake> <04e4cb50-8cba-58af-1a5e-61e818cffa70@suse.cz> <alpine.DEB.2.20.1711070948410.19176@nuc-kabylake>
 <4b08f1e9-5449-6ea2-e7da-65fe5f678683@huawei.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfHDAEkjOkfc0yuVoI90pI+0hySZ1dSKaZkwvv5fLj7As3RfSFQa2RKRCf48nVvT9sFIpkpJ/mGGD+doT8cKhh/t03HM0nCRwJQhJRNeRlxGRGmaH2OLh
 2iPSvLwQ9DF3YkRZXzIBonc791g0/pBWTe8otb4aHpycRhT454CL7rXT/uxL+nto7TUq7rP83ogbO3m/4hac2CXf0ICbqYFG2CkNS04zqcZ5mpNBKDxt+8PR
 A+RaBnzr9KDR8mHsu2yFMaJ9IPV9YSnbMLDXhLKVFtAJblzQi1qM7AGajUe600BUy6nt9zNhKbgFHnDOnanICd1s0cDXnFGR+0A2exNS18RuWQLsK0VPZq80
 fwhKUnwJ3oOWcZg7D/cUthidNgVz7od/azc4cOpDhRkLIYj1U80eSxESCAlrO5NM7kgjAr8j5ITZJkLKL1PiZS8Xy3wYdPds4tTFpZjsuXHcWy4S5MKmjXty
 eS5LSVisXWUpWLtkLDiy21e1ioioXN57BCAHSW0CviMMAMmoGBf6Jbf2bnb1nzH1SnqgJkZh/3nqL6Jl
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 8 Nov 2017, Yisheng Xie wrote:

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

The caller of migrate_pages should be able to migrate the target process
pages anywhere the caller can allocate memory. If that is outside the
target processes cpuset then that is fine. Pagecache pages that are not
allocated by the target process already are not subject to the target
processes restriction. So this is not that unusual.