From: Johannes Berg <johannes@sipsolutions.net>
To: Jacob Shin <jacob.shin@amd.com>
Cc: davej@codemonkey.org.uk, Ashok Raj <ashok.raj@intel.com>,
cpufreq <cpufreq@lists.linux.org.uk>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>,
mark.langsdorf@amd.com
Subject: Re: CPU hotplug vs. cpufreq on ppc64
Date: Mon, 05 Feb 2007 18:33:30 +0100 [thread overview]
Message-ID: <1170696810.3572.28.camel@johannes.berg> (raw)
In-Reply-To: <45C765C3.3090004@amd.com>
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Hi,
> CPU0 comes online first, and no other CPUs are online yet. CPU0 cannot
> advertise to cpufreq what his affected CPUs are because CPU1, CPU2, and
> CPU3 do not exist!
Actually, the current powermac cpufreq code does (and can because it
knows that there are only 4 CPUs that you can't actually hotplug
physically.)
> At this point in time, the kernel is only aware of
> CPU0, which is the only CPU that cpufreq manages for the moment.
Right, the current cpufreq code still sets policy->cpus = 1|2|4|8
though.
> Now, say CPU1 comes online. CPU1 now knows that itself and CPU0 are
> tied together in freq scaling.
Aha, so the knowledge should be the other way around.
> However, CPU0 is still left in the dark,
> and thinks that he only manages himself. So CPU1 will register itself,
> and tell cpufreq that its affected cpus are itself and CPU0. The
> cpufreq driver will see that CPU0 is already managed, update CPU0's
> affected cpus data structure, symlink CPU1 to CPU0, and finally call
> exit on CPU1 to clean up.
Ok.
> Same story for CPU2 and CPU3.
Yeah, I understand now. Thanks for the explanation. I think the fix is
actually trivial too.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
prev parent reply other threads:[~2007-02-05 17:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-01 20:14 CPU hotplug vs. cpufreq on ppc64 Johannes Berg
2007-02-05 1:39 ` Benjamin Herrenschmidt
2007-02-05 6:45 ` Johannes Berg
2007-02-05 17:13 ` Jacob Shin
2007-02-05 17:33 ` Johannes Berg [this message]
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=1170696810.3572.28.camel@johannes.berg \
--to=johannes@sipsolutions.net \
--cc=ashok.raj@intel.com \
--cc=cpufreq@lists.linux.org.uk \
--cc=davej@codemonkey.org.uk \
--cc=jacob.shin@amd.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mark.langsdorf@amd.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).