From: Hakan BAYINDIR <hakan@bayindir.org>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: "cpufreq@lists.linux.org.uk" <cpufreq@lists.linux.org.uk>
Subject: Re: Q6600 CPU Frequency Scaling Problem / Bug
Date: Mon, 30 Jun 2008 23:33:05 +0300 [thread overview]
Message-ID: <48694301.30707@bayindir.org> (raw)
In-Reply-To: <7E82351C108FA840AB1866AC776AEC46066E6834@orsmsx505.amr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 3767 bytes --]
Pallipadi, Venkatesh wrote:
>> -----Original Message-----
>> From: cpufreq-bounces@lists.linux.org.uk
>> [mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of Hakan BAYINDIR
>> Sent: Monday, June 30, 2008 12:51 PM
>> To: cpufreq@lists.linux.org.uk
>> Subject: Q6600 CPU Frequency Scaling Problem / Bug
>>
>> Hi,
>>
>> I'm running Debian testing on an Intel Core2Quad Q6600 with
>> 4GB DDR2 RAM
>> on a MSI P35 Platinum board since December 07. When I first migrated my
>> system on December (I've installed Debian as etch beta1 and upgrading
>> since), every core of the CPU was scaling their frequency
>> independently.
>> After installing 2.6.22, The cores started to scale in a synchronized
>> way. I.e. when a core needs to speed-up, every core speeds up in sync.
>> The weird thing is, I have another clone of this OS at my
>> office running
>> on a core 2 duo processor and that system scaled its processors
>> independently.
>>
>> The ganged scaling behavior is also consistent with the
>> /sys/devices/system/cpuX/cpufreq/affected_cpus file and cpufreq-info
>> command. Both of them shows that all CPU's speeds are need to
>> be in sync
>> while there's really no need. Also Ubuntu 8.04 Live CD
>> exhibits the same
>> behavior and this behavior can be verified under sysfs again.
>>
>> Is it a bug? Is it expected? I can provide more information if it's
>> needed. I'm attaching cpufreq-info's output as a reference.
>>
>>
>
> Just to confirm what I understood:
> - Older kernels, each logical CPU can show different frequencies and affected_cpus has only once CPU number in it.
> - Newer kernel, logical CPUs show same freq and affected_cpus includes all CPUs in the platform.
>
> Correct?
> In this case it seems to be the expected behavior.
>
> In actual hardware, voltage is coordinated at socket level and that is the reason frequencies in one socket are tied together. Now, what has changed in two above config will be the mode in which kernel operates:
> 1) Hardware coordination mode: Kernel thinks each core is having independent frequency and reports the same. Underneath, hardware does frequency coodination and picks the highest requested frequency among all cores and runs all cores at that freq.
> 2) Software coordination mode: Kernel understands which specific CPUs are dependent and picks the highest frequency needed among all such dependent cores and makes single request for such frequency and reports the same.
>
> Note that there should not be any power consumption difference with these two kernels on under identical load. Just that the kernel now knows more about the frequency dependencies in the platform.
>
> Thanks,
> Venki
>
>
Hi again,
No this is not the case because, none of my CPUs are logical. I have one
true quad core and I true dual core CPU package. Each cores in these
cpus are real and complete (not hyper threading CPUs). When I was
running 2.6.21, both quad core and dual core systems were scaling its
speeds independently per core. Currently, while my dual core system is
continuing to do it, my quad core cpu is not doing it. Instead, it syncs
its speed.
In reality, Core2Quad Q6600 is two Core2Duo E6600s. As A result I'm
running a 2xDual Core CPUs in one package which each dual core CPU can
scale every of its core independently from each other and when I run a
single threaded intensive job, all of my cores scale up and I can see
its effects in the output of sensors command. If the cores were logical
or not-complete, Syncing should be the thing to do but When I'm running
two of my office PC's CPUs (literally) in one package, it's hard to
understand this behavior.
Thanks for reply,
Cheers and Regards,
--Hakan.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 147 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq
next prev parent reply other threads:[~2008-06-30 20:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-30 19:50 Q6600 CPU Frequency Scaling Problem / Bug Hakan BAYINDIR
2008-06-30 20:21 ` Pallipadi, Venkatesh
2008-06-30 20:33 ` Hakan BAYINDIR [this message]
2008-06-30 21:07 ` Pallipadi, Venkatesh
2008-06-30 21:19 ` Hakan BAYINDIR
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=48694301.30707@bayindir.org \
--to=hakan@bayindir.org \
--cc=cpufreq@lists.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;
as well as URLs for NNTP newsgroup(s).