From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Gautham R Shenoy <ego@in.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Oleg Nesterov <oleg@tv-sign.ru>
Subject: [RFD] CPU hotplug and suspend
Date: Fri, 6 Apr 2007 17:32:31 +0200 [thread overview]
Message-ID: <200704061732.32712.rjw@sisk.pl> (raw)
Hi,
Currently, we use the CPU hotplug to disable nonboot CPUs in the suspend code
paths, but with the recent change of code ordering (ie. nonboot CPUs are
disabled after freezing tasks _and_ devices) it has become quite troublesome.
The reason of this is that there are some CPU hotplug notifiers registered and
called on each run of cpu_up()/cpu_down() that assume the system to be fully
functional, which is not the case during the suspend. Moreover, at least some
of them do things that are not really necessary for disabling or enabling the
nonboot CPUs.
For example, it doesn't seem to be necessary to stop worker threads bound to
the nonboot CPUs when they are disabled, because these CPUs most likely
reappear during the resume. This particular problem has caused us to make all
workqueus nonfreezable, although at least some of them should be freezable, as
far as the suspend is concerned.
The advantage of using the CPU hotplug (in its current form) for suspending is
that if some CPUs don't reappear during the resume, we are safe. Still, I
think it would be more appropriate, and simpler in the long run, to notify the
interested subsystems _only_ if one (or more) CPUs are not functional after the
resume. In fact, with the current code ordering the subsystems don't even need
to know that we have disabled and enabled the nonboot CPUs, unless something
goes wrong.
For this reason, I'd like to change the suspend code to use a simplified CPU
management, sharing some low-level code with the current CPU hotplug, that
won't call all of the CPU hotplug notifiers at all, but will be able to call
some other special notifiers in case one (or more) of the nonboot CPUs cannot
be enabled. Of course, that would require the subsystems to register separate
CPU notifiers for the resume, but I think they may share some code with the
current CPU hotplug notifiers.
It seems to me that we should separate the special case of suspend from the
"run-time" CPU hotplug, or things will get more and more complicated over time.
Still, that would be quite radical redesign, so I'm not sure if it's generally
acceptable.
Please advise.
Greetings,
Rafael
next reply other threads:[~2007-04-06 15:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-06 15:32 Rafael J. Wysocki [this message]
2007-04-06 15:56 ` Eric W. Biederman
2007-04-09 14:03 ` Pavel Machek
2007-04-09 13:14 ` Rafael J. Wysocki
2007-04-16 7:01 ` Pavel Machek
2007-04-15 22:27 ` [RFC][PATCH][EXPERIMENTAL] CPU hotplug with frozen tasks Rafael J. Wysocki
2007-04-16 7:05 ` Pavel Machek
2007-04-16 21:06 ` Rafael J. Wysocki
2007-04-16 9:50 ` Gautham Shenoy
2007-04-16 21:27 ` Rafael J. Wysocki
2007-04-18 9:42 ` Gautham R Shenoy
2007-04-18 17:07 ` Rafael J. Wysocki
2007-04-23 19:19 ` Oleg Nesterov
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=200704061732.32712.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=pavel@ucw.cz \
--cc=vatsa@in.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
all inboxes | Powered by JetHome®