linux-kernel - Re: [PATCH] cpufreq: ondemand: Introduces stepped frequency increase

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4e5e476b0907140744qb2cf9cajc1c5dbbeba2ab66d@mail.gmail.com>
Date:	Tue, 14 Jul 2009 16:44:57 +0200
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Matthew Garrett <mjg@...hat.com>, Dave Jones <davej@...hat.com>,
	linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org
Subject: Re: [PATCH] cpufreq: ondemand: Introduces stepped frequency increase

On Fri, Jul 10, 2009 at 1:34 AM, Pavel Machek<pavel@....cz> 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@...hat.com> 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@...alhost hd]# echo powersave >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[root@...alhost hd]# time ./time_me
3.19user 0.11system 0:03.36elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+16506minor)pagefaults 0swaps
[root@...alhost hd]# echo performance >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[root@...alhost hd]# time ./time_me
3.06user 0.07system 0:03.18elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+16506minor)pagefaults 0swaps
[root@...alhost hd]# echo  ondemand >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[root@...alhost hd]# echo 5 >
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/freq_step
[root@...alhost 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@...il.com
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/