From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Alan Stern <stern@rowland.harvard.edu>,
paulmck@linux.vnet.ibm.com, Ingo Molnar <mingo@elte.hu>,
paul@paulmenage.org, 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: Mon, 13 Feb 2012 23:17:12 +0530 [thread overview]
Message-ID: <4F394CA0.9020902@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F35EE11.5010202@linux.vnet.ibm.com>
On 02/11/2012 09:56 AM, Srivatsa S. Bhat wrote:
> On 02/11/2012 07:37 AM, Peter Zijlstra wrote:
>
>> On Fri, 2012-02-10 at 23:39 +0100, Rafael J. Wysocki wrote:
>>>
>>>> I don't see why not. Presumably no CPUs will be added or removed while
>>>> the system is asleep.
>>>
>>> ACPI explicitly forbids that level of hardware reconfiguration in a sleep
>>> state (even in S4), AFAICS. Still, people may try to do that ...
>>
>> I'm ok with breaking that :-) If its really really important to someone
>> we (him most likely) could fix it by detecting the topology changed over
>> the suspend and do a fixup. Assuming it actually gets that far.
>>
>> Srivatsa, wanna give this (the proposal to not modify cpusets on
>> CPU_TASKS_FROZEN) a try?
>>
>
>
> Sure! After you pointed out that CPU Hotplug is destructive in general and
> hence it is not a good idea to put back online CPUs to cpusets, the next
> thing I thought of trying was a special case handling for suspend/resume
> alone, IOW, not calling the cpuset update upon CPU_TASKS_FROZEN.
>
> So, yes, I'll write up a patch for that and post it soon :-)
>
Trivially removing CPU_TASKS_FROZEN as shown below doesn't look right to me:
---
kernel/sched/core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5255c9d..43a166e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6729,7 +6729,7 @@ int __init sched_create_sysfs_power_savings_entries(struct device *dev)
static int cpuset_cpu_active(struct notifier_block *nfb, unsigned long action,
void *hcpu)
{
- switch (action & ~CPU_TASKS_FROZEN) {
+ switch (action) {
case CPU_ONLINE:
case CPU_DOWN_FAILED:
cpuset_update_active_cpus();
@@ -6742,7 +6742,7 @@ static int cpuset_cpu_active(struct notifier_block *nfb, unsigned long action,
static int cpuset_cpu_inactive(struct notifier_block *nfb, unsigned long action,
void *hcpu)
{
- switch (action & ~CPU_TASKS_FROZEN) {
+ switch (action) {
case CPU_DOWN_PREPARE:
cpuset_update_active_cpus();
return NOTIFY_OK;
IMO, irrespective of whether we keep cpusets unaware of all CPU Hotplug or
only unaware of the CPU hotplug in the suspend/resume path, I feel the
scheduler should always know the true state of the system, ie., offline CPUs
must not be part of any sched domain, at any point in time.
At the moment, I am exploring several ways to achieve this (I can think of 2
ways at the moment, will see which one is better). But in case this approach
itself seems wrong for any reason, please let me know.
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-02-13 17:47 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 [this message]
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 ` [PATCH 0/4] CPU hotplug, cpusets: Fix CPU online handling related to cpusets Paul E. McKenney
2012-02-13 17:47 ` 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=4F394CA0.9020902@linux.vnet.ibm.com \
--to=srivatsa.bhat@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=paulmck@linux.vnet.ibm.com \
--cc=pjt@google.com \
--cc=prashanth@linux.vnet.ibm.com \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).