Re: cpufreq question

[Jarod Wilson <jwilson@redhat.com>]

On Wednesday 14 May 2008 04:47:40 pm Pallipadi, Venkatesh wrote:
> Cpuspeed does not try to change freq more than once in few seconds. So,
> I don't understand 'threads competing with each other to push CPU up and
> down' part. The way things will work is cpuspeed looks at utilization of
> each CPU and picks a freq target for the CPU. Hardware picks the highest
> freq req among all CPUs in a socket and uses that for the whole socket.

There's a problem with the cpuspeed daemon when its first fired up. For a 
multi-core system, it starts up independent processes for each core, all of 
which start probing their core for available steppings. If the timing is just 
right, one probe (b) can stomp on another (a) by changing the frequency for 
another core, which changes it for all cores, and thus probe b screws up the 
available stepping detection routine for probe a. We've kludged around this 
by having the probe routine try setting a given frequency a few times if it 
gets unexpected results. Dirty hack, but the cpuspeed daemon is mostly the 
way of the dodo in anything more modern than RHEL4.


> If cpuspeed is not changing freq even when the CPU is 100% utilized over
> few seconds, then it should be some bug in cpuspeed (IIRC, there is a
> verbose mode in cpuspeed that should tell why it is not increasing the
> freq on that core).
>
> On a side note, you should also be able to use ondemand which does more
> fine grained freq management.
> #modprobe cpufreq_ondemand
> #echo ondemand > /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor
> // for all CPUs X=0,1,2,3

Yep, ondemand is the way we go by default on everything newer than RHEL4, not 
sure what our level of support is like for ondemand on RHEL4...


> >-----Original Message-----
> >From: cpufreq-bounces@lists.linux.org.uk
> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of Frazier, John
> >Sent: Wednesday, May 14, 2008 12:32 PM
> >To: Langsdorf, Mark; Jarod Wilson; cpufreq@lists.linux.org.uk
> >Subject: RE: cpufreq question
> >
> >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



-- 
Jarod Wilson
jwilson@redhat.com