All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:14:19 +0530	[thread overview]
Message-ID: <4FBE02F3.3030809@linux.vnet.ibm.com> (raw)
In-Reply-To: <1337850827.9783.77.camel@laptop>

On 05/24/2012 02:43 PM, Peter Zijlstra wrote:

> On Thu, 2012-05-17 at 22:33 +0530, Srivatsa S. Bhat wrote:
>> +               /*
>> +                * Restore only the top_cpuset because it has to track
>> +                * cpu_active_mask always.
>> +                * (We don't need to do anything if we come here during resume
>> +                * from suspend, since top_cpuset.cpus_allowed will already be
>> +                * equal to cpu_active_mask.)
>> +                */
>> +               if (root == &top_cpuset && !cpumask_equal(root->cpus_allowed,
>> +                                                         cpu_active_mask)) {
>> +                       mutex_lock(&callback_mutex);
>> +                       cpumask_copy(root->cpus_allowed, cpu_active_mask);
>> +                       mutex_unlock(&callback_mutex);
>> +                       update_tasks_cpumask(root, NULL);
>> +               } 
> 
> This looks absolutely broken.
> 
> Suppose I set an explicit cpu affinity mask on my task, which per not
> using cpusets is in the root group.
> 
> If I then do a hotplug cycle, I'll find my affinity mask is lost.
> 


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

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

Is the above understanding correct?

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?

Regards,
Srivatsa S. Bhat


  reply	other threads:[~2012-05-24 10:34 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 [this message]
2012-05-24 11:58       ` Peter Zijlstra
2012-05-24 12:24         ` Srivatsa S. Bhat
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=4FBE02F3.3030809@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.