Re: [PATCH RFC v2 4/4] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux