From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
paul@paulmenage.org, rjw@sisk.pl, tj@kernel.org,
frank.rowand@am.sony.com, pjt@google.com, tglx@linutronix.de,
lizf@cn.fujitsu.com, prashanth@linux.vnet.ibm.com,
vatsa@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/4] CPU hotplug, cpusets: Fix CPU online handling related to cpusets
Date: Sat, 11 Feb 2012 08:00:40 -0800 [thread overview]
Message-ID: <20120211160040.GA6616@linux.vnet.ibm.com> (raw)
In-Reply-To: <1328895244.25989.25.camel@laptop>
On Fri, Feb 10, 2012 at 06:34:04PM +0100, Peter Zijlstra wrote:
> On Fri, 2012-02-10 at 08:53 -0800, Paul E. McKenney wrote:
> > On Fri, Feb 10, 2012 at 04:52:07PM +0100, Peter Zijlstra wrote:
> > > On Thu, 2012-02-09 at 16:11 +0100, Ingo Molnar wrote:
> > >
> > > > > My understanding of the code is that when a CPU is taken
> > > > > offline, it is removed from all the cpusets and then the
> > > > > scan_for_empty_cpusets() function is run to move tasks from
> > > > > empty cpusets to their parent cpusets.
> > > >
> > > > Why is that done that way? offlining a CPU should be an
> > > > invariant as far as cpusets are concerned.
> > >
> > > Can't, tasks need to run someplace. There's two choices, add a still
> > > online cpu to the now empty cpuset or move the tasks to a parent that
> > > still has online cpus.
> > >
> > > Both are destructive.
> >
> > OK, I will ask the stupid question... Hey, somebody has to! ;-)
> >
> > Would it make sense for offlining the last CPU in a cpuset to be
> > destructive, but to allow offlining of a non-last CPU to be reversible?
>
> No, that's very inconsistent and will lead to way more 'surprises'.
It might well lead to surprises, but so does INT_MIN==-INT_MIN. IOW,
the inconsistency certainly is a disadvantage, but it must be weighed
against the disadvantages of the current situation.
> > /me ducks. ;-)
>
> /me quacks ;-)
>
> Now the whole problem here seems to be that suspend uses cpu-hotplug to
> reduce the machine to UP -- I've no clue why it does that but I can
> imagine its because the BIOS calls only work on CPU0 and/or the resume
> only wakes CPU0 so you have to bootstrap the SMP thing again..
>
> Some suspend person wanna clarify? Rafael?
>
> Anyway, the whole suspend case is magic anyway since all tasks will have
> been frozen, so we could simply leave all of cpuset alone and ignore the
> hotplug notifier on CPU_TASKS_FROZEN callbacks, hmm?
>
> Do we unfreeze after we bring up the machine again?
Agreed, the suspend case is the highest priority in that losing your cpusets
after suspending and resuming is -very- surprising. ;-)
Thanx, Paul
next prev parent reply other threads:[~2012-02-11 16:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-07 18:55 [PATCH 0/4] CPU hotplug, cpusets: Fix CPU online handling related to cpusets Srivatsa S. Bhat
2012-02-07 18:56 ` [PATCH 1/4] CPU hotplug, cpuset: Maintain a copy of the cpus_allowed mask before CPU hotplug Srivatsa S. Bhat
2012-02-07 18:56 ` [PATCH 2/4] cpuset: Split up update_cpumask() so that its functionality can be reused Srivatsa S. Bhat
2012-02-07 18:57 ` [PATCH 3/4] cpuset: Add function to introduce CPUs to cpusets during CPU online Srivatsa S. Bhat
2012-02-07 18:57 ` [PATCH 4/4] CPU hotplug, cpusets: Differentiate the CPU online and CPU offline callbacks Srivatsa S. Bhat
2012-02-08 3:22 ` [PATCH 0/4] CPU hotplug, cpusets: Fix CPU online handling related to cpusets Peter Zijlstra
2012-02-08 6:33 ` Srivatsa S. Bhat
2012-02-09 7:57 ` Ingo Molnar
2012-02-09 8:42 ` Srivatsa S. Bhat
2012-02-09 15:11 ` Ingo Molnar
2012-02-10 15:52 ` Peter Zijlstra
2012-02-10 16:53 ` Paul E. McKenney
2012-02-10 17:34 ` Peter Zijlstra
2012-02-10 21:51 ` Alan Stern
2012-02-10 22:39 ` Rafael J. Wysocki
2012-02-11 2:07 ` Peter Zijlstra
2012-02-11 4:26 ` Srivatsa S. Bhat
2012-02-13 17:47 ` Srivatsa S. Bhat
2012-02-17 12:15 ` Srivatsa S. Bhat
2012-02-20 12:49 ` Peter Zijlstra
2012-02-20 12:59 ` Srivatsa S. Bhat
2012-02-23 9:57 ` Srivatsa S. Bhat
2012-02-24 23:24 ` Rafael J. Wysocki
2012-02-27 10:18 ` Peter Zijlstra
2012-02-27 12:09 ` [tip:sched/urgent] CPU hotplug, cpusets, suspend: Don' t touch cpusets during suspend/resume tip-bot for Srivatsa S. Bhat
2012-02-11 16:00 ` Paul E. McKenney [this message]
2012-02-13 17:47 ` [PATCH 0/4] CPU hotplug, cpusets: Fix CPU online handling related to cpusets Srivatsa S. Bhat
2012-02-13 20:39 ` Paul E. McKenney
2012-02-13 20:49 ` Srivatsa S. Bhat
2012-02-11 13:39 ` Ingo Molnar
2012-02-10 15:53 ` Peter Zijlstra
2012-02-09 16:43 ` Peter Zijlstra
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=20120211160040.GA6616@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=frank.rowand@am.sony.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=paul@paulmenage.org \
--cc=pjt@google.com \
--cc=prashanth@linux.vnet.ibm.com \
--cc=rjw@sisk.pl \
--cc=srivatsa.bhat@linux.vnet.ibm.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.