* RE: cpufreq question
2008-05-14 19:31 ` Frazier, John
@ 2008-05-14 20:47 ` Pallipadi, Venkatesh
2008-05-14 20:54 ` Jarod Wilson
2008-05-16 21:58 ` Carl Thompson
` (3 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Pallipadi, Venkatesh @ 2008-05-14 20:47 UTC (permalink / raw)
To: Frazier, John, Langsdorf, Mark, Jarod Wilson, cpufreq
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
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: cpufreq question
2008-05-14 20:47 ` Pallipadi, Venkatesh
@ 2008-05-14 20:54 ` Jarod Wilson
0 siblings, 0 replies; 16+ messages in thread
From: Jarod Wilson @ 2008-05-14 20:54 UTC (permalink / raw)
To: Pallipadi, Venkatesh; +Cc: Frazier, John, cpufreq
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cpufreq question
2008-05-14 19:31 ` Frazier, John
2008-05-14 20:47 ` Pallipadi, Venkatesh
@ 2008-05-16 21:58 ` Carl Thompson
2008-05-16 22:01 ` Carl Thompson
` (2 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Carl Thompson @ 2008-05-16 21:58 UTC (permalink / raw)
Cc: cpufreq
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: cpufreq question
2008-05-14 19:31 ` Frazier, John
2008-05-14 20:47 ` Pallipadi, Venkatesh
2008-05-16 21:58 ` Carl Thompson
@ 2008-05-16 22:01 ` Carl Thompson
2008-05-16 22:03 ` Carl Thompson
2008-05-16 22:05 ` Carl Thompson
4 siblings, 0 replies; 16+ messages in thread
From: Carl Thompson @ 2008-05-16 22:01 UTC (permalink / raw)
Cc: cpufreq
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: cpufreq question
2008-05-14 19:31 ` Frazier, John
` (2 preceding siblings ...)
2008-05-16 22:01 ` Carl Thompson
@ 2008-05-16 22:03 ` Carl Thompson
2008-05-16 22:05 ` Carl Thompson
4 siblings, 0 replies; 16+ messages in thread
From: Carl Thompson @ 2008-05-16 22:03 UTC (permalink / raw)
Cc: cpufreq
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: cpufreq question
2008-05-14 19:31 ` Frazier, John
` (3 preceding siblings ...)
2008-05-16 22:03 ` Carl Thompson
@ 2008-05-16 22:05 ` Carl Thompson
4 siblings, 0 replies; 16+ messages in thread
From: Carl Thompson @ 2008-05-16 22:05 UTC (permalink / raw)
Cc: cpufreq
[-- 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
^ permalink raw reply [flat|nested] 16+ messages in thread