From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: mingo@kernel.org, pjt@google.com, paul@paulmenage.org,
akpm@linux-foundation.org, rjw@sisk.pl, nacc@us.ibm.com,
rientjes@google.com, paulmck@linux.vnet.ibm.com,
tglx@linutronix.de, seto.hidetoshi@jp.fujitsu.com, tj@kernel.org,
mschmidt@redhat.com, berrange@redhat.com,
nikunj@linux.vnet.ibm.com, vatsa@linux.vnet.ibm.com,
liuj97@gmail.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org
Subject: Re: [PATCH v5 4/5] cpusets: Update tasks' cpus_allowed mask upon updates to root cpuset
Date: Thu, 24 May 2012 17:54:47 +0530 [thread overview]
Message-ID: <4FBE288F.8060802@linux.vnet.ibm.com> (raw)
In-Reply-To: <1337860736.9783.123.camel@laptop>
On 05/24/2012 05:28 PM, Peter Zijlstra wrote:
> On Thu, 2012-05-24 at 15:14 +0530, Srivatsa S. Bhat wrote:
>
>> Sorry, my bad, I hadn't considered that. Thanks for pointing it out!
>>
>> So, I am wondering how we ought to deal with CPU hotplug for tasks attached
>> to the root cpuset..
>
> By not doing anything at all. If a task is in the root set it is
> supposed to behave as it cpusets don't exist.
>
>> Considering tasks attached to the root cpuset, if a cpu present in a task's
>> cpus_allowed mask goes offline, it should be removed from that mask right?
>
> Nope, that shouldn't happen. We only reset the mask if all cpus in the
> affinity mask go away. This is where task affinity and cpusets differ.
>
>> And if that cpu comes back online, it should not be put back to the task's
>> cpus_allowed mask (just like we don't put back cpus in non-root cpusets).
>
> Online shouldn't ever change anything.
>
>> Is the above understanding correct?
>
> Nope.
>
>> In the current kernel, during cpu hotplug, we don't touch cpus_allowed mask
>> of the tasks attached to the root cpuset at all.. Whereas we update the
>> cpus_allowed mask of tasks belonging to non-root cpusets, during cpu offline.
>>
>> So, is this differentiation intended?
>
> Yes, although arguably the cpuset case is 'weird' in that it came later
> and didn't mirror the cpu affinity semantics.
>
> Tasks aren't attached to the root cpuset, they live there because
> there's no other place to be when you don't use cpusets. This very much
> means that tasks in the root set should behave as if cpusets didn't
> exist.
>
Ok, got it.. that logic makes sense. Thanks a lot for the explanation!
I will resubmit this patchset without patch 4/5 then, if you don't have any
other objections.
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-05-24 12:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 16:59 [PATCH v5 0/5] CPU hotplug, cpusets, suspend/resume: Fixes, cleanups and optimizations Srivatsa S. Bhat
2012-05-17 16:59 ` [PATCH v5 1/5] CPU hotplug, cpusets, suspend: Don't modify cpusets during suspend/resume Srivatsa S. Bhat
2012-05-17 17:00 ` [PATCH v5 2/5] cpusets, hotplug: Implement cpuset tree traversal in a helper function Srivatsa S. Bhat
2012-05-17 17:00 ` [PATCH v5 3/5] cpusets, hotplug: Restructure functions that are invoked during hotplug Srivatsa S. Bhat
2012-05-17 17:03 ` [PATCH v5 4/5] cpusets: Update tasks' cpus_allowed mask upon updates to root cpuset Srivatsa S. Bhat
2012-05-24 9:13 ` Peter Zijlstra
2012-05-24 9:44 ` Srivatsa S. Bhat
2012-05-24 11:58 ` Peter Zijlstra
2012-05-24 12:24 ` Srivatsa S. Bhat [this message]
2012-05-17 17:03 ` [PATCH v5 5/5] cpusets: Remove/update outdated comments Srivatsa S. Bhat
2012-05-20 13:58 ` [PATCH v5 0/5] CPU hotplug, cpusets, suspend/resume: Fixes, cleanups and optimizations Srivatsa S. Bhat
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=4FBE288F.8060802@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=berrange@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=mingo@kernel.org \
--cc=mschmidt@redhat.com \
--cc=nacc@us.ibm.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paul@paulmenage.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pjt@google.com \
--cc=rientjes@google.com \
--cc=rjw@sisk.pl \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vatsa@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.