Re: cpufreq question

[Carl Thompson <cet@carlthompson.net>]

[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]


Your problem probably doesn't have anything to do with nice time
counting as idle time. You're correct when you say the threads are
competing to control the CPU speed.

The problem is that older kernels like the one shipped with RHEL4 don't
expose enough information via cpufreq for CPUSpeed to know what cores
are tied to other cores and should be controlled together. That's what
the "affected_cpus" file does. Older kernels (and older versions of
CPUSpeed) just assumed that the processor cores were independent which
is not true for most CPUs including your Xeons. This causes older
versions of CPUSpeed (and whatever modified version Red Hat is shipping)
to fight with itself for control of CPUs.

You can try the attached version which allows you manually specify the
CPU cores that are tied together by using the "-S" option. You must run
a separate copy of CPUSpeed for each physical CPU (technically for each
group of tied CPU cores). In your case for two Xeon dual-core processors
where the cores of each processor are tied together you should run it
like this:

    cpuspeed -S "0 1" [<other options>]
    cpuspeed -S "2 3" [<other options>]

Note that the quotes are required.

Let me know if this works for you.

Thank you,
Carl Thompson

PS: On my test systems (running 2.6.25) I've noticed that processes seem
to have no natural affinity for a particular core. Processes (regardless
of how much CPU they're using) seem to move between cores frequently.
I'm not sure what the purpose of this process shuffling is but it can
cause CPUSpeed to switch speeds instead of staying at a constant level.
I suspect the various governors that perform a similar function are also
affected by this. I hope there's a way to tune this behavior somewhere...

-------- Original Message  --------
Subject: Re: cpufreq question
From: Frazier, John <j-frazier2@ti.com>
To: Langsdorf, Mark <mark.langsdorf@amd.com>, Jarod Wilson
<jwilson@redhat.com>, cpufreq@lists.linux.org.uk
Date: Wed May 14 2008 12:31:38 GMT-0700 (PDT)
> Mark,
>
> Thanks for your answer. 
>
> I am using  Intel(R) Xeon(R) CPU           X5260  @ 3.33GHz X 2 cpus
>
> 1. When cpuspeed starts there are 4 daemons.
> 2. In many situations I see the cpuspeed bouncing radically back and
> forth between min to max.
> 3. Eventually I will see that the cpu core 0 will be pegged at 100% but
> the speed will be 2K.
>
> I think that I am dealing with a 2 fold problem. One being that cpuspeed
> counts nice time as idle. The other one is that I think that the threads
> are competing to push the cpu up and down.
>
> Regards,
>  
> John Frazier
>
> -----Original Message-----
> From: Langsdorf, Mark [mailto:mark.langsdorf@amd.com] 
> Sent: Wednesday, May 14, 2008 2:20 PM
> To: Frazier, John; Jarod Wilson; cpufreq@lists.linux.org.uk
> Subject: RE: cpufreq question
>
>  
>   
>> The version I am running is 1.2.1 and it works somewhat however I am
>> having some issues with the dual core cpus not scaling correctly. That
>> is what led me down this path. I got a new version of 
>> cpuspeed from Carl
>> Thomas and it does need the affected_cpus file which of course is not
>> there. Is there a way to just add the file? 
>>     
>
> There are two ways to add the file:
> 	edit your kernel to change drivers/cpufreq/cpufreq.c to 
> create the additional sysfs file.  You'll also need to correctly
> fill it with data, which you could either get from the device
> driver or just hardcode for your particular machine.
>
> or
> 	update to any kernel past about 2.6.16 that will have
> the affected_cpus file.
>
> Either of these will make it difficult to get service from Red
> Hat, as you've altered the kernel and they only support the 
> kernel they provided.
>
> If you don't want to change your kernel, you need to revert 
> to the cpuspeed version that came with your product and 
> complain to your vendor about how it isn't handling dual CPUs
> correctly.
>
> Speaking of which: how is it not handling dual CPUs correctly?
> It might be doing the right thing.  Dual-core AMD Opterons, when 
> running on RHEL4, are supposed to run at the frequency of the
> busier core, for example.
>
> -Mark Langsdorf
> Operating System Research Center
> AMD
>
>
> _______________________________________________
> Cpufreq mailing list
> Cpufreq@lists.linux.org.uk
> http://lists.linux.org.uk/mailman/listinfo/cpufreq
>
>   


[-- Attachment #2: cpuspeed.tar.gz --]
[-- Type: application/x-gzip, Size: 13985 bytes --]

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq