[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d49801b-01cd-579b-f731-d6ca7aed985d@amazon.de>
Date: Tue, 18 Sep 2018 15:54:03 +0200
From: "Jan H. Schönherr" <jschoenh@...zon.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
Paul Turner <pjt@...gle.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Morten Rasmussen <morten.rasmussen@....com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Rik van Riel <riel@...riel.com>
Subject: Re: Task group cleanups and optimizations (was: Re: [RFC 00/60]
Coscheduling for Linux)
On 09/18/2018 03:38 PM, Peter Zijlstra wrote:
> On Tue, Sep 18, 2018 at 03:22:13PM +0200, Jan H. Schönherr wrote:
>> AFAIK, changing the affinity of a cpuset overwrites the individual affinities of tasks
>> within them. Thus, it shouldn't be an issue.
>
> No, it only shrinks the set. Also nothing stops you calling
> sched_setaffinity() once you're inside the cpuset. The only contraint is
> that your mask is a subset of the cpuset mask.
I meant setting the affinity of the cpuset *after* setting an individual affinity.
Like this:
# mkdir /sys/fs/cgroup/cpuset/test
# cat /sys/fs/cgroup/cpuset/cpuset.mems > /sys/fs/cgroup/cpuset/test/cpuset.mems
# cat /sys/fs/cgroup/cpuset/cpuset.cpus > /sys/fs/cgroup/cpuset/test/cpuset.cpus
# echo $$ > /sys/fs/cgroup/cpuset/test/tasks
# taskset -c -p 0 $$
pid 4745's current affinity list: 0-3
pid 4745's new affinity list: 0
# echo "0-1" > /sys/fs/cgroup/cpuset/test/cpuset.cpus
# taskset -c -p $$
pid 4745's current affinity list: 0,1
#
The individual affinity of $$ is lost, despite it being a subset.
Powered by blists - more mailing lists