Re: ondemand cpufreq ineffective in 2.6.12 ?

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Daniel J Blueman]

I find the ondemand governor works as expected with 2.6.12 on my
Athlon64 Winchester [1]; as soon as I bzip2 a file, processor freq is
pinned at 1.8GHz and drops to 1GHz when idle.

--- [1]

$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 31
model name      : AMD Athlon(tm) 64 Processor 3000+
stepping        : 0
cpu MHz         : 1004.646
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow
bogomips        : 1988.83
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Ken Moffat wrote:
> Hi,
> 
>  I've been using the ondemand governor on athlon64 winchesters for a few
> weeks.  I've just noticed that in 2.6.12 the frequency is not
> increasing under load, it remains at the lowest frequency.  This seems
> to be down to something in 2.6.12-rc6, but I've seen at least one report
> since then that ondemand works fine.  Anybody else seeing this problem ?
> 
>  Testcase: boot (my bootscripts set the governor to ondemand), set the
> governor to ondemand, performance, powersave and untar a nice big
> bzip2'd tarball (gcc-3.4.1) from an nfs mount. All using the config from
> 2.6.11.9 and defaults for new options.
> 
> kernel		2.6.11.9	2.6.12-rc5	2.6.12-rc6	2.6.12
> 
> ondemand	20.8 sec	21.3 sec	33.9 sec	34.1 sec
> performance	21.3 sec	22.0 sec	22.6 sec	20.1 sec
> powersave	32.4 sec	33.1 sec	33.6 sec	33.9 sec
> 
> I don't have confidence that the numbers are more repeatable than +/- 2
> seconds on this, they just illustrate that ondemand used to give a
> similar time to performance, but now doesn't.  Other intermediate and
> later tests have been omitted for clarity, but 2.6.12.2 does show the
> same problem.
> 
> Since 2.6.12-rc6, 'ondemand' appears to be still accepted (the echo to
> scaling_governor returns 0, and the displayed frequency drops back if
> I try going from performance to ondemand).
> 
> When ondemand appears to work properly, /proc/cpuinfo shows the speed
> jumping to 2 GHz, then falling back to 1.8 after the untar ends, then
> back to 1.0 GHz.  In the problem cases, the speed remains at 1GHz.
> 
> As far as I can see, nothing untoward shows in the logs.  Any
> suggestions, please ?
> 
> Ken
___
Daniel J Blueman

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Ken Moffat]

On Tue, 12 Jul 2005, Daniel J Blueman wrote:

> I find the ondemand governor works as expected with 2.6.12 on my
> Athlon64 Winchester [1]; as soon as I bzip2 a file, processor freq is
> pinned at 1.8GHz and drops to 1GHz when idle.
>

 Thanks, it seems to be a niceness problem - if I run from an xterm as a
user, the processes get a niceness of 10.  If the bzip2 process gets
reniced to 0, all is sweetness.  So, either I have to not use X, or
stick with 2.6.11.

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas]

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

On Wed, 13 Jul 2005 00:57, Lee Revell wrote:
> On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
> > > Well, it's just the default settings of the kernel which has changed.
> > > If you want the old behaviour, you can use (with your admin hat): echo
> > > 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice IMHO it
> > > seems quite fair, if you have a process nice'd to 10 it probably means
> > > you are not in a hurry.
> >
> > That's not necessarily true. Most people use 'nice' to have the cpu bound
> > task not affect their foreground applications, _not_ because they don't
> > care how long they take.
>
> But the scheduler should do this on its own!

That is a most unusual thing to tell the person who tuned the crap out of the 
2.6 scheduler so that it would do this.

> If people are having to 
> renice kernel compiles to maintain decent interactive performance (and
> yes, I have to do the same thing sometimes) the scheduler is BROKEN,
> period.

Two tasks being the same nice level still implies they should receive the same 
proportion of cpu. Anything else breaks the implied fairness of nice levels. 
Whether you agree with this approach or not, it is expected. No, cpu 
distribution is never _perfectly_ split 50/50 when nice levels are the same 
but we try our best to do so while maintaining interactivity. 

A more useful argument would be that you'd like to have two sets of nice 
levels - one perhaps called latnice implying which tasks you want latency 
critical but still want to have the same cpu and one called cpunice which 
affects the amount of cpu but not the latency. Some would like complete 
control over both nices while others want the scheduler to do everything for 
them. Either way, you want a compile to be both latnice and cpunice. Our 
current nice is both latnice and cpunice, and if nice levels are equal the 
scheduler does a heck of a lot of its own latnice based on behaviour. It's 
not perfect and nothing ever is. 

Cheers,
Con

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Lee Revell]

On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
> > Well, it's just the default settings of the kernel which has changed. If
> > you want the old behaviour, you can use (with your admin hat):
> > echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
> > IMHO it seems quite fair, if you have a process nice'd to 10 it probably
> > means you are not in a hurry.
> 
> That's not necessarily true. Most people use 'nice' to have the cpu bound task 
> not affect their foreground applications, _not_ because they don't care how 
> long they take.

But the scheduler should do this on its own!  If people are having to
renice kernel compiles to maintain decent interactive performance (and
yes, I have to do the same thing sometimes) the scheduler is BROKEN,
period.

Lee

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Ken Moffat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 229 bytes --]

On Tue, 12 Jul 2005, Eric Piel wrote:

>
> Just by couriosity, I wonder how your processes are automatically
> reniced to 10 ?
>

 In my case, running from an xterm.

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas]

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

On Tue, 12 Jul 2005 21:49, Eric Piel wrote:
> 07/12/2005 01:11 PM, Ken Moffat wrote/a écrit:
> > On Tue, 12 Jul 2005, Ken Moffat wrote:
> >> I was going to say that niceness didn't affect what I was doing, but
> >>I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up
> >>with a niceness of 10.  I'm starting to feel a bit out of my depth here
> >
> > OK, Con was right, and I didn't initially make the connection.
> >
> >  In 2.6.11, untarring a .tar.bz2 causes tar and bzip2 to run with a
> > niceness of 10, but everything is fine.
> >
> >  In 2.6.12, ondemand _only_ has an effect for me in this example if I
> > put on my admin hat and renice the bzip2 process (tried 0, that works) -
> > renicing the tar process has no effect (obviously, that part doesn't
> > push the processor).
> >
> > So, from a user's point of view it's broken.
>
> Well, it's just the default settings of the kernel which has changed. If
> you want the old behaviour, you can use (with your admin hat):
> echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
> IMHO it seems quite fair, if you have a process nice'd to 10 it probably
> means you are not in a hurry.

That's not necessarily true. Most people use 'nice' to have the cpu bound task 
not affect their foreground applications, _not_ because they don't care how 
long they take. I nice my kernel compiles and keep web browsing etc (actually 
I run them SCHED_BATCH but this has the same effect with the default ondemand 
governor now).

>
> Just by couriosity, I wonder how your processes are automatically
> reniced to 10 ?

Shell environment settings.

Cheers,
Con

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Eric Piel]

07/12/2005 01:11 PM, Ken Moffat wrote/a écrit:
> On Tue, 12 Jul 2005, Ken Moffat wrote:
> 
> 
>> I was going to say that niceness didn't affect what I was doing, but
>>I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up
>>with a niceness of 10.  I'm starting to feel a bit out of my depth here
> 
> 
> OK, Con was right, and I didn't initially make the connection.
> 
>  In 2.6.11, untarring a .tar.bz2 causes tar and bzip2 to run with a
> niceness of 10, but everything is fine.
> 
>  In 2.6.12, ondemand _only_ has an effect for me in this example if I
> put on my admin hat and renice the bzip2 process (tried 0, that works) -
> renicing the tar process has no effect (obviously, that part doesn't
> push the processor).
> 
> So, from a user's point of view it's broken.
Well, it's just the default settings of the kernel which has changed. If 
you want the old behaviour, you can use (with your admin hat):
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
IMHO it seems quite fair, if you have a process nice'd to 10 it probably 
means you are not in a hurry.

Just by couriosity, I wonder how your processes are automatically 
reniced to 10 ?


Eric

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Ken Moffat]

On Tue, 12 Jul 2005, Ken Moffat wrote:

>  I was going to say that niceness didn't affect what I was doing, but
> I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up
> with a niceness of 10.  I'm starting to feel a bit out of my depth here

OK, Con was right, and I didn't initially make the connection.

 In 2.6.11, untarring a .tar.bz2 causes tar and bzip2 to run with a
niceness of 10, but everything is fine.

 In 2.6.12, ondemand _only_ has an effect for me in this example if I
put on my admin hat and renice the bzip2 process (tried 0, that works) -
renicing the tar process has no effect (obviously, that part doesn't
push the processor).

So, from a user's point of view it's broken.

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Ken Moffat]

On Tue, 12 Jul 2005, Eric Piel wrote:

> It's a tradeoff :-)
>
> Ken, does this solve your problems (but that seems strange that all your
> tasks are nice'd) ?
>
> Eric
>

 I was going to say that niceness didn't affect what I was doing, but
I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up
with a niceness of 10.  I'm starting to feel a bit out of my depth here
...

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Eric Piel]

11.07.2005 23:55, Con Kolivas wrote/a écrit:
> On Tue, 12 Jul 2005 05:45, Ken Moffat wrote:
> 
>>On Mon, 11 Jul 2005, Ken Moffat wrote:
>>
>>>Hi,
>>>
>>> I've been using the ondemand governor on athlon64 winchesters for a few
>>>weeks.  I've just noticed that in 2.6.12 the frequency is not
>>>increasing under load, it remains at the lowest frequency.  This seems
>>>to be down to something in 2.6.12-rc6, but I've seen at least one report
>>>since then that ondemand works fine.  Anybody else seeing this problem ?
>>
>> And just for the record, it's still not working in 2.6.13-rc2.  Oh
>>well, back to 2.6.11 for this box.
> 
> 
> I noticed a change in ondemand on pentiumM, where it would not ramp up if the 
> task using cpu was +niced. It does ramp up if the task is not niced. This 
> seems to have been considered all round better but at my end it is not - if 
> it takes the same number of cycles to complete a task it does not save any 
> battery running it at 600Mhz vs 1700Mhz, it just takes longer. Yes I know 
> during the initial ramp up the 1700Mhz one will waste more battery, but that 
> is miniscule compared to something that burns cpu constantly for 10 mins. Now 
> I'm forced to run my background tasks at nice 0 and not get the benefit of 
> nicing the tasks, _or_ I have to go diddling with settings in /sys to disable 
> this feature or temporarily move to the performance governor.
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
Put it once for all in your initscript :-)

> Although I 
> complained lightly initially when this change was suggested, I didn't realise 
> it was actually going to become standard. 
I like it because it avoids that any background task which is ran makes 
the fans turning like hell. It's also very advantageous with tasks like 
screensavers or a la seti@home (but few people have this on their laptop).

> 
> To me the ondemand governor was supposed to not delay you at all, but cause as 
> much battery saving as possible without noticeable slowdown...
> 
> Oh well you can't please everyone all the time.
It's a tradeoff :-)

Ken, does this solve your problems (but that seems strange that all your 
tasks are nice'd) ?

Eric

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas]

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

On Tue, 12 Jul 2005 05:45, Ken Moffat wrote:
> On Mon, 11 Jul 2005, Ken Moffat wrote:
> > Hi,
> >
> >  I've been using the ondemand governor on athlon64 winchesters for a few
> > weeks.  I've just noticed that in 2.6.12 the frequency is not
> > increasing under load, it remains at the lowest frequency.  This seems
> > to be down to something in 2.6.12-rc6, but I've seen at least one report
> > since then that ondemand works fine.  Anybody else seeing this problem ?
>
>  And just for the record, it's still not working in 2.6.13-rc2.  Oh
> well, back to 2.6.11 for this box.

I noticed a change in ondemand on pentiumM, where it would not ramp up if the 
task using cpu was +niced. It does ramp up if the task is not niced. This 
seems to have been considered all round better but at my end it is not - if 
it takes the same number of cycles to complete a task it does not save any 
battery running it at 600Mhz vs 1700Mhz, it just takes longer. Yes I know 
during the initial ramp up the 1700Mhz one will waste more battery, but that 
is miniscule compared to something that burns cpu constantly for 10 mins. Now 
I'm forced to run my background tasks at nice 0 and not get the benefit of 
nicing the tasks, _or_ I have to go diddling with settings in /sys to disable 
this feature or temporarily move to the performance governor. Although I 
complained lightly initially when this change was suggested, I didn't realise 
it was actually going to become standard. 

To me the ondemand governor was supposed to not delay you at all, but cause as 
much battery saving as possible without noticeable slowdown...

Oh well you can't please everyone all the time. 

Con

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Ken Moffat]

On Mon, 11 Jul 2005, Ken Moffat wrote:

> Hi,
>
>  I've been using the ondemand governor on athlon64 winchesters for a few
> weeks.  I've just noticed that in 2.6.12 the frequency is not
> increasing under load, it remains at the lowest frequency.  This seems
> to be down to something in 2.6.12-rc6, but I've seen at least one report
> since then that ondemand works fine.  Anybody else seeing this problem ?
>

 And just for the record, it's still not working in 2.6.13-rc2.  Oh
well, back to 2.6.11 for this box.

-- 
 das eine Mal als Tragödie, das andere Mal als Farce

ondemand cpufreq ineffective in 2.6.12 ?

[Ken Moffat]

Hi,

 I've been using the ondemand governor on athlon64 winchesters for a few
weeks.  I've just noticed that in 2.6.12 the frequency is not
increasing under load, it remains at the lowest frequency.  This seems
to be down to something in 2.6.12-rc6, but I've seen at least one report
since then that ondemand works fine.  Anybody else seeing this problem ?

 Testcase: boot (my bootscripts set the governor to ondemand), set the
governor to ondemand, performance, powersave and untar a nice big
bzip2'd tarball (gcc-3.4.1) from an nfs mount. All using the config from
2.6.11.9 and defaults for new options.

kernel		2.6.11.9	2.6.12-rc5	2.6.12-rc6	2.6.12

ondemand	20.8 sec	21.3 sec	33.9 sec	34.1 sec
performance	21.3 sec	22.0 sec	22.6 sec	20.1 sec
powersave	32.4 sec	33.1 sec	33.6 sec	33.9 sec

I don't have confidence that the numbers are more repeatable than +/- 2
seconds on this, they just illustrate that ondemand used to give a
similar time to performance, but now doesn't.  Other intermediate and
later tests have been omitted for clarity, but 2.6.12.2 does show the
same problem.

Since 2.6.12-rc6, 'ondemand' appears to be still accepted (the echo to
scaling_governor returns 0, and the displayed frequency drops back if
I try going from performance to ondemand).

When ondemand appears to work properly, /proc/cpuinfo shows the speed
jumping to 2 GHz, then falling back to 1.8 after the untar ends, then
back to 1.0 GHz.  In the problem cases, the speed remains at 1GHz.

As far as I can see, nothing untoward shows in the logs.  Any
suggestions, please ?

Ken
-- 
 das eine Mal als Tragödie, das andere Mal als Farce