cpufreq question

cpufreq question

[Frazier, John]

I am new to Linux and I am having a little problem with my cpu power
saving.

 

Kernel: 2.6.9-67.0.4.ELsmp

 

I am using cpuspeed to control my cpus and I have just upgraded to a
newer version of it and it is looking for the file
/sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus.

This file does not exist on my system. What is the correct way to
resolve this issue?

 

Thank you,

 

John Frazier

Re: cpufreq question

[Jarod Wilson]

On Wednesday 14 May 2008 02:28:02 pm Frazier, John wrote:
> I am new to Linux and I am having a little problem with my cpu power
> saving.
>
> Kernel: 2.6.9-67.0.4.ELsmp
>
> I am using cpuspeed to control my cpus and I have just upgraded to a
> newer version of it and it is looking for the file
> /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus.
>
> This file does not exist on my system. What is the correct way to
> resolve this issue?

Probably best to file a bug at bugzilla.redhat.com for issues on a RHEL4 
system -- wildly divergent from upstream by now. :) Will need some additional 
info though, along the lines of what cpu(s) you have, what architecture and 
what cpuspeed version and/or kernel-utils version you have 
('rpm -qf /etc/init.d/cpuspeed' should get the right answer).

-- 
Jarod Wilson
jwilson@redhat.com

RE: cpufreq question

[Langsdorf, Mark]

> On Wednesday 14 May 2008 02:28:02 pm Frazier, John wrote:
> > I am new to Linux and I am having a little problem with my cpu power
> > saving.
> >
> > Kernel: 2.6.9-67.0.4.ELsmp
> >
> > I am using cpuspeed to control my cpus and I have just upgraded to a
> > newer version of it and it is looking for the file
> > /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus.
> >
> > This file does not exist on my system. What is the correct way to
> > resolve this issue?
> 
> Probably best to file a bug at bugzilla.redhat.com for issues 
> on a RHEL4 system -- wildly divergent from upstream by now. 

RHEL4 doesn't support 
/sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus and 
cpuspeed 1.2.1 requires them.  You need to revert to a 
previous version of cpuspeed, such as the one that came
with your RHEL4 installation.  Current versions of RHEL4
support SMP/CMP cpufreq with their native tools.

-Mark Langsdorf
Operating System Research Center
AMD

RE: cpufreq question

[Frazier, John]

Mark,
Mark,

Please excuse my ignorance but when I look at the help for cpuspeed on
the box:
cpuspeed -help
========================================================================
cpuspeed v1.2.1

This program monitors the system's idle percentage and reduces or raises
the
CPUs' clock speeds and voltages accordingly to minimize power
consumption
when idle and maximize performance when needed.  This is the default.

The program may also optionally be configured to reduce the CPUs' clock
speeds if the temperature gets too high, NOT minimize their speeds if
the
computer's AC adapter is disconnected or maximize their speeds when the
AC
adapter is connected.

By default this program will manage every CPU found in the system.
 
 Left the rest off.

========================================================================

Then when I look in /sys/system/devices/cpu
ls /sys/devices/system/cpu/*/cpufreq
========================================================================
/sys/devices/system/cpu/cpu0/cpufreq:
cpuinfo_cur_freq  cpuinfo_min_freq
scaling_available_governors  scaling_driver    scaling_max_freq
scaling_setspeed
cpuinfo_max_freq  scaling_available_frequencies  scaling_cur_freq
scaling_governor  scaling_min_freq

/sys/devices/system/cpu/cpu1/cpufreq:
cpuinfo_cur_freq  cpuinfo_min_freq
scaling_available_governors  scaling_driver    scaling_max_freq
scaling_setspeed
cpuinfo_max_freq  scaling_available_frequencies  scaling_cur_freq
scaling_governor  scaling_min_freq

/sys/devices/system/cpu/cpu2/cpufreq:
cpuinfo_cur_freq  cpuinfo_min_freq
scaling_available_governors  scaling_driver    scaling_max_freq
scaling_setspeed
cpuinfo_max_freq  scaling_available_frequencies  scaling_cur_freq
scaling_governor  scaling_min_freq

/sys/devices/system/cpu/cpu3/cpufreq:
cpuinfo_cur_freq  cpuinfo_min_freq
scaling_available_governors  scaling_driver    scaling_max_freq
scaling_setspeed
cpuinfo_max_freq  scaling_available_frequencies  scaling_cur_freq
scaling_governor  scaling_min_freq
========================================================================
====

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? 


Thanks,
 
John Frazier

-----Original Message-----
From: Langsdorf, Mark [mailto:mark.langsdorf@amd.com] 
Sent: Wednesday, May 14, 2008 1:53 PM
To: Jarod Wilson; cpufreq@lists.linux.org.uk
Cc: Frazier, John
Subject: RE: cpufreq question

> On Wednesday 14 May 2008 02:28:02 pm Frazier, John wrote:
> > I am new to Linux and I am having a little problem with my cpu power
> > saving.
> >
> > Kernel: 2.6.9-67.0.4.ELsmp
> >
> > I am using cpuspeed to control my cpus and I have just upgraded to a
> > newer version of it and it is looking for the file
> > /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus.
> >
> > This file does not exist on my system. What is the correct way to
> > resolve this issue?
> 
> Probably best to file a bug at bugzilla.redhat.com for issues 
> on a RHEL4 system -- wildly divergent from upstream by now. 

RHEL4 doesn't support 
/sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus and 
cpuspeed 1.2.1 requires them.  You need to revert to a 
previous version of cpuspeed, such as the one that came
with your RHEL4 installation.  Current versions of RHEL4
support SMP/CMP cpufreq with their native tools.

-Mark Langsdorf
Operating System Research Center
AMD

RE: cpufreq question

[Langsdorf, Mark]

 
> 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

Re: cpufreq question

[Jarod Wilson]

On Wednesday 14 May 2008 02:52:37 pm Langsdorf, Mark wrote:
> > On Wednesday 14 May 2008 02:28:02 pm Frazier, John wrote:
> > > I am new to Linux and I am having a little problem with my cpu power
> > > saving.
> > >
> > > Kernel: 2.6.9-67.0.4.ELsmp
> > >
> > > I am using cpuspeed to control my cpus and I have just upgraded to a
> > > newer version of it and it is looking for the file
> > > /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus.
> > >
> > > This file does not exist on my system. What is the correct way to
> > > resolve this issue?
> >
> > Probably best to file a bug at bugzilla.redhat.com for issues
> > on a RHEL4 system -- wildly divergent from upstream by now.
>
> RHEL4 doesn't support
> /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus and
> cpuspeed 1.2.1 requires them.  You need to revert to a
> previous version of cpuspeed, such as the one that came
> with your RHEL4 installation.  Current versions of RHEL4
> support SMP/CMP cpufreq with their native tools.

Erm, RHEL4 has been shipping cpuspeed 1.2.1 since mid 2005... From the 
kernel-utils changelog:

* Mon Jun 20 2005 Dave Jones <davej@redhat.com>
- Update cpuspeed to 1.2.1, featuring improved dual-core/SMP support. 
(#146179)


-- 
Jarod Wilson
jwilson@redhat.com

RE: cpufreq question

[Langsdorf, Mark]

> > RHEL4 doesn't support
> > /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus and
> > cpuspeed 1.2.1 requires them.  You need to revert to a
> > previous version of cpuspeed, such as the one that came
> > with your RHEL4 installation.  Current versions of RHEL4
> > support SMP/CMP cpufreq with their native tools.
> 
> Erm, RHEL4 has been shipping cpuspeed 1.2.1 since mid 2005... 
> From the kernel-utils changelog:
> 
> * Mon Jun 20 2005 Dave Jones <davej@redhat.com>
> - Update cpuspeed to 1.2.1, featuring improved dual-core/SMP support. 
> (#146179)

Apologies for the misinformation.

But I'm reasonably sure it isn't stock cpuspeed-1.2.1, 
which is what John apparently installed.

-Mark Langdorf
Operating System Research Center
AMD

Re: cpufreq question

[Jarod Wilson]

On Wednesday 14 May 2008 03:11:48 pm Frazier, John wrote:
[...]
> 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.

Does this ring a bell?

https://bugzilla.redhat.com/show_bug.cgi?id=392781

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

What new version? 1.2.1 was released back in 2005, I don't see anything 
newer...

> Is there a way to just add the file? 

No. Its not actually a file. sysfs is a pseudo file system, which exposes 
assorted kernel interfaces, not something you can just add files to.


-- 
Jarod Wilson
jwilson@redhat.com

RE: cpufreq question

[Frazier, John]

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

Re: cpufreq question

[Jarod Wilson]

On Wednesday 14 May 2008 03:25:22 pm Langsdorf, Mark wrote:
> > > RHEL4 doesn't support
> > > /sys/devices/system/cpu/cpu%u/cpufreq/affected_cpus and
> > > cpuspeed 1.2.1 requires them.  You need to revert to a
> > > previous version of cpuspeed, such as the one that came
> > > with your RHEL4 installation.  Current versions of RHEL4
> > > support SMP/CMP cpufreq with their native tools.
> >
> > Erm, RHEL4 has been shipping cpuspeed 1.2.1 since mid 2005...
> > From the kernel-utils changelog:
> >
> > * Mon Jun 20 2005 Dave Jones <davej@redhat.com>
> > - Update cpuspeed to 1.2.1, featuring improved dual-core/SMP support.
> > (#146179)
>
> Apologies for the misinformation.
>
> But I'm reasonably sure it isn't stock cpuspeed-1.2.1,
> which is what John apparently installed.

Yeah, its not 100% stock, but I don't see anything major we're patching in or 
out of it... Latest RHEL4.7 srpm:

http://people.redhat.com/jwilson/misc/kernel-utils-2.4-14.1.116.src.rpm


-- 
Jarod Wilson
jwilson@redhat.com

RE: cpufreq question

[Pallipadi, Venkatesh]

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.

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

Thanks,
Venki

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

Re: cpufreq question

[Jarod Wilson]

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

Re: cpufreq question

[Carl Thompson]

[-- 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

Re: cpufreq question

[Carl Thompson]

[-- 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

Re: cpufreq question

[Carl Thompson]

[-- 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

Re: cpufreq question

[Carl Thompson]

[-- 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