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 S1757494AbdKGPzv (ORCPT <rfc822;w@1wt.eu>);
        Tue, 7 Nov 2017 10:55:51 -0500
Received: from resqmta-ch2-09v.sys.comcast.net ([69.252.207.41]:34978 "EHLO
        resqmta-ch2-09v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1752092AbdKGPzu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 7 Nov 2017 10:55:50 -0500
Date: Tue, 7 Nov 2017 09:55:47 -0600 (CST)
From: Christopher Lameter <cl@linux.com>
X-X-Sender: cl@nuc-kabylake
To: Vlastimil Babka <vbabka@suse.cz>
cc: Yisheng Xie <xieyisheng1@huawei.com>, 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: <04e4cb50-8cba-58af-1a5e-61e818cffa70@suse.cz>
Message-ID: <alpine.DEB.2.20.1711070948410.19176@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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfEFCjAz/2O6lUbpbxCS+sO6hkhle243PC0zdJr6XzDGZnsPH+dpQkrsnAPx4QVml01AFWjbPYDvwNNVHFqQGgjK/MnlSr6yIjOxPrXm3WxiYah5ZCbKM
 LGq8YZec+/4Enxd1R+z+h8lvEipmK6AqZiLS7qTtmtiNpdaGBnoW4zc/vWGkDIm8NKwCDOa8+7lf/jAJC5xseRHOfcF/fswiMyGY8uP5vIAuYzqYQl9Y19Ur
 5rZrwboAK5IVtb9CT2fucBDOkNIo8KDS28vLoJF3Q17GePZOlk1XTLvpZ/niUB83wHEFyJOKLKDKHA2jMvZNDw8G388zoE+VMXkUExOh4v/RkLaqH81KWJIN
 UTHEmXRKsxQuEVCjdzpaPgPLyzLdb9RJ46LOjcWC+hrbU7x1+vf+HJ/doBy4U+AtBXHJzSlguTD/xBnDeGir29UKpwTg2+m22BFwgwL1kvWU0sNgZU4Rxrsh
 lBMGG+eRjFN9UDvCtwdIKWjTsOS8gPm4OrG1okwbN3FXZrmHou1fdYSmse2dmPBfFbf14mGUH5UCLpQB
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

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.