From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
rdunlap@xenotime.net, len.brown@intel.com, pavel@ucw.cz,
a.p.zijlstra@chello.nl, linux-pm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Documentation/power: Update docs about suspend and CPU hotplug
Date: Fri, 14 Oct 2011 23:48:14 +0530 [thread overview]
Message-ID: <4E987CE6.10501@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1110141140080.2036-100000@iolanthe.rowland.org>
On 10/14/2011 09:14 PM, Alan Stern wrote:
> On Fri, 14 Oct 2011, Srivatsa S. Bhat wrote:
>
>> Update the documentation about the interaction between the suspend (S3) call
>> path and the CPU hotplug infrastructure.
>> This patch focusses only on the activities of the freezer, cpu hotplug and
>> the notifications involved. It outlines how regular CPU hotplug differs from
>> the way it is invoked during suspend and also tries to explain the locking
>> involved.
>>
>> v2: Clarified the question, to emphasize that the document explains only
>> the difference (and similarity) in the two code paths but not what happens
>> when race conditions occur between them.
>
> Drawing the two diagrams in parallel, the way this does, carries a very
> strong implication that the events being described happen in parallel.
> It really would be much better to have two separate diagrams and point
> out the common portions.
>
I felt that drawing this way side-by-side would make it easier to see where they
differ and where they call the same code. But if this is really causing everyone
to believe that it represents events happening in parallel, then I will think
of separating the two diagrams and still somehow effectively explain what I set
out to explain in this document. Thank you for pointing it out.
> Also, the document should discuss the issues involved in CPU hotplug.
> In particular, what happens if the CPUs are not all the same, or if the
> requiring differing microcodes. And whether or not the microcode needs
> to get reloaded (presumably only after hibernation, not after suspend).
> And what happens when a CPU is hot-unplugged and replaced with a
> differeing CPU which is then hot-plugged.
>
Ok, I'll add another section that deals with the whole CPU hotplug and microcode
story. I'll include it in the next version. Thank you.
--
Regards,
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Linux Technology Center,
IBM India Systems and Technology Lab
next prev parent reply other threads:[~2011-10-14 18:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-11 20:19 [PATCH] Documentation/power: Update docs about suspend and CPU hotplug Srivatsa S. Bhat
2011-10-11 22:02 ` Rafael J. Wysocki
2011-10-12 4:17 ` Srivatsa S. Bhat
2011-10-12 19:19 ` Rafael J. Wysocki
2011-10-12 21:13 ` Srivatsa S. Bhat
2011-10-14 6:24 ` [PATCH v2] " Srivatsa S. Bhat
2011-10-14 15:44 ` Alan Stern
2011-10-14 18:18 ` Srivatsa S. Bhat [this message]
2011-10-17 13:10 ` [PATCH v3] " Srivatsa S. Bhat
2011-10-19 22:08 ` Rafael J. Wysocki
2011-10-15 22:42 ` [PATCH] " Rafael J. Wysocki
2011-10-16 0:14 ` 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=4E987CE6.10501@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=len.brown@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rdunlap@xenotime.net \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
/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