From: Dave Jones <davej@redhat.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, cpufreq@www.linux.org.uk
Subject: Re: cpufreq & dual core CPUs.
Date: Wed, 31 May 2006 00:54:17 -0400 [thread overview]
Message-ID: <20060531045417.GA9439@redhat.com> (raw)
In-Reply-To: <88056F38E9E48644A0F562A38C64FB60085E063E@scsmsx403.amr.corp.intel.com>
On Tue, May 30, 2006 at 09:40:37PM -0700, Pallipadi, Venkatesh wrote:
> I am assuming speedstep-centrino is being used here.
yes, sorry for omitting that, though I'm not sure this problem
is unique to Intel CPUs, though powernow-k8 does seem to have
some awareness of the cpu_core_map
> This one core
> reducing the frequency of the other core is not supposed to happen. The
> way it is handled in Core Duo or later CPUs is:
> 1) We can either use software coordination when BIOS and OS supports it.
> In which case, OS will know that these two CPUs are tied together and
> controls both of them using one interface. However, the users of this
> one common interface, cpuspeed or ondemand governor should be aware of
> this fact that one interface controls two CPUs (by looking at the
> affected_cpus in cpufreq directory). Ondemand handles this today. But,
> cpuspeed. I am not sure.
Looking at that file on my core duo laptop, I see ..
(00:47:47:davej@exile:~)$ cat /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus
0
(00:47:54:davej@exile:~)$ cat /sys/devices/system/cpu/cpu1/cpufreq/affected_cpus
1
That implies to me that they're separate cores no?
> 2) More easier way is to do this coordination in hardware. Each Cpu will
> write to their own MSR. Hardware will pick the maximum frequency of the
> two MSR and controls the package at that frequency. This is the default
> mode on most of Core Duo based platforms and we have found that this is
> more effient in the sense that each CPU can indepently control the
> frequency, with no set_cpu_allowed() and friends in the path.
>
> Basically, with hardware coordination, you should not see this
> particular issue. I feel, there is something broken in this particular
> case and I will look into it closer tomorrow. My guess at this point is,
> this is due to userlevel governor, which looks at utilization over a
> period of time (few seconds) and then decides on the frequency. This can
> be checked with ondemand governor, which should handle this case much
> better.
ondemand does behave better than userspace does, but something is
still amiss given that they can both still be set to individual
values.
This..
(00:52:15:davej@exile:~)$ grep MHz /proc/cpuinfo
cpu MHz : 1000.000
cpu MHz : 2167.000
Should never happen on a dual core system that has synchronised cores.
Either they're both running at 1GHz, or they're both running at 2.1GHz.
(That was with both cpu0 & cpu1 set to use ondemand governor).
Dave
--
http://www.codemonkey.org.uk
next prev parent reply other threads:[~2006-05-31 4:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-31 4:40 cpufreq & dual core CPUs Pallipadi, Venkatesh
2006-05-31 4:54 ` Dave Jones [this message]
2006-05-31 5:05 ` Jacob Shin
2006-06-03 4:32 ` Carl Thompson
-- strict thread matches above, loose matches on Subject: below --
2006-05-31 14:10 Pallipadi, Venkatesh
2006-05-31 5:02 Pallipadi, Venkatesh
2006-05-31 5:33 ` Dominik Brodowski
2006-06-23 6:50 ` Dominik Brodowski
2006-05-31 4:26 Dave Jones
2006-05-31 4:59 ` Jacob Shin
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=20060531045417.GA9439@redhat.com \
--to=davej@redhat.com \
--cc=akpm@osdl.org \
--cc=cpufreq@www.linux.org.uk \
--cc=venkatesh.pallipadi@intel.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