Re: [PATCH] cpufreq: ondemand: Introduces stepped frequency increase

[Corrado Zoccolo]

On Fri, Jul 10, 2009 at 1:34 AM, Pavel Machek<pavel@xxxxxx> wrote:
> On Wed 2009-07-08 19:41:23, Corrado Zoccolo wrote:
>> Hi Matthew,
>>
>> On Wed, Jul 8, 2009 at 6:10 PM, Matthew Garrett<mjg@xxxxxxxxxx> wrote:
>> > On Wed, Jul 08, 2009 at 03:56:33PM +0200, Corrado Zoccolo wrote:
>> >> The patch introduces a new sysfs tunable cpufreq/ondemand/freq_step,
>> >> as found in conservative governor, to chose the frequency increase step,
>> >> expressed as percentage (default = 100 is previous behaviour).
>> >>
>> >> This allows fine tuning powersaving on mobile CPUs, since smaller steps will allow to:
>> >> * absorb punctual load spikes
>> >> * stabilize at the needed frequency, without passing for more power consuming states, and
>> >
>> > Is this a measured powersaving? The ondemand model is based on the
>> > assumption that the idle state is disproportionately lower in power than
>> > any running state, and therefore it's more sensible to run flat out for
>> > short periods of time than run at half speed for longer. Is this
>> > inherently flawed, or is it an artifact of differences in your processor
>> > design?
>
> Different processors behave differently -- that assumption is wrong at
> least for old athlon64s... Those have power-hungry idle states, and 4x
> power consumption at 2x frequency....
>
> (Original Intel speedstep was similar iirc).

Actually, I think that if the assumption was completely fulfilled by
some hardware, the 'performance' governor would be better than
cpufreq, since it would have less latency, and reach idle faster.
However, even for recent hardware, at least states C1/C2 drain more
power at higher frequencies, so cpufreq is actually useful, and
avoiding unnecessary peaks (as this patch intends to do) can be useful
as well.

Moreover. as I said before, for some processors, the performances are
not directly proportional to the core frequency, but depend on the
workload.

For example: on Pentium M (banias), with frequency ranging from 600 to 1300MHz,
the following program, compiled with -O3 -funroll-loops:
#include <stdlib.h>
#define SIZE 16*1024*1024
#define TYPE long
int main() {
  TYPE * memory=(TYPE*)calloc(SIZE,sizeof(TYPE));
  int i, j;
  for (j=0; j<20; ++j)
    for (i=1; i<SIZE-1; ++i)
      memory[i] += memory[i-1] + memory[i+1];

  return 0;
}

achieves:
[root@localhost hd]# echo powersave >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[root@localhost hd]# time ./time_me
3.19user 0.11system 0:03.36elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+16506minor)pagefaults 0swaps
[root@localhost hd]# echo performance >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[root@localhost hd]# time ./time_me
3.06user 0.07system 0:03.18elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+16506minor)pagefaults 0swaps
[root@localhost hd]# echo  ondemand >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[root@localhost hd]# echo 5 >
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/freq_step
[root@localhost hd]# sleep 5; time ./time_me
2.90user 0.11system 0:03.18elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+16506minor)pagefaults 0swaps

it has only 9% performance decrease passing from 1300MHz to 600MHz,
and the difference between performance and ondemand with
(freq_step=5%) is not measurable.

The same program on an Atom doesn't show the same effect. It seems
that Atoms scale also the FSB frequency together with core frequency.

Corrado

>
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ÂPavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>



-- 
__________________________________________________________________________

dott. Corrado Zoccolo                          mailto:czoccolo@xxxxxxxxx
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/