linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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 --]

      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).