All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stratos Karafotis <stratosk@semaphore.gr>
To: Pavel Machek <pavel@ucw.cz>
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] cpufreq: ondemand: Eliminate the deadband effect
Date: Mon, 21 Jul 2014 08:41:58 +0300	[thread overview]
Message-ID: <53CCA826.1070809@semaphore.gr> (raw)
In-Reply-To: <20140720215151.GA7817@amd.pavel.ucw.cz>

On 21/07/2014 12:51 πμ, Pavel Machek wrote:
> Hi!
> 
>>>>>> Tested on Intel i7-3770 CPU @ 3.40GHz and on ARM quad core 1500MHz Krait
>>>>>> (Android smartphone).
>>>>>> Benchmarks on Intel i7 shows a performance improvement on low and medium
>>>>>> work loads with lower power consumption. Specifics:
>>>>>>
>>>>>> Phoronix Linux Kernel Compilation 3.1:
>>>>>> Time: -0.40%, energy: -0.07%
>>>>>> Phoronix Apache:
>>>>>> Time: -4.98%, energy: -2.35%
>>>>>> Phoronix FFMPEG:
>>>>>> Time: -6.29%, energy: -4.02%
>>>>>
>>>>> Hmm. Intel i7 should be race-to-idle machine. So basically rule like
>>>>> if (load > 0) go to max frequency else go to lowest frequency would do
>>>>> the right thing in your test, right?
>>>>
>>>> I don't think that "if (load > 0) go to max" will work even on i7.
>>>> For low load this will have impact on energy consumption.
>>>
>>> Are you sure? CPU frequency should not matter on idle CPU.
>>
>> Even on a totally idle CPU there will be a small impact because of leakage
>> current (thanks to Dirk Brandewie for this info).
> 
> Are you sure? IIRC Intel cpus will automatically lower CPU frequency
> in deep C states..

I'm sorry. I don't know further details about the leakage current
in deeper C states.

>> This simple test on a nearly idle system shows this:
>>
>> [root@albert cpufreq]# for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done
>> [root@albert cpufreq]# /home/stratosk/kernels/linux-pm/tools/power/x86/turbostat/turbostat -J sleep 20
>>     Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7   Pkg_J   Cor_J   GFX_J   time
>>        -       -       2    0.06    2712    3392       0    0.30    0.00   99.63    0.00      34      34    8.09    0.00   81.94    0.00  380.41   14.51    1.64   20.00
>>        0       0       0    0.02    1891    3392       0    0.09    0.00   99.88    0.00      34      34    8.09    0.00   81.94    0.00  380.41   14.51    1.64   20.00
>>        0       4       1    0.04    3006    3392       0    0.07
>>        1       1       1    0.04    2501    3392       0    0.62    0.00   99.33    0.00      34
>>        1       5       0    0.01    2346    3392       0    0.66
>>        2       2       0    0.01    1996    3392       0    0.44    0.00   99.55    0.00      34
>>        2       6       4    0.18    2278    3392       0    0.26
>>        3       3       5    0.15    3449    3392       0    0.07    0.01   99.77    0.00      34
>>        3       7       0    0.01    1839    3392       0    0.21
>> 20.000899 sec
>> [root@albert cpufreq]# ^C
>> [root@albert cpufreq]# for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n ondemand > $CPUFREQ; done
>> [root@albert cpufreq]# /home/stratosk/kernels/linux-pm/tools/power/x86/turbostat/turbostat -J sleep 20
>>     Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7   Pkg_J   Cor_J   GFX_J   time
>>        -       -       2    0.09    1693    3392       0    0.35    0.01   99.55    0.00      35      36    8.33    0.00   84.31    0.00  377.68   12.23    1.15   20.00
>>        0       0       1    0.08    1603    3392       0    0.13    0.00   99.79    0.00      35      36    8.33    0.00   84.31    0.00  377.68   12.23    1.15   20.00
>>        0       4       1    0.08    1646    3392       0    0.13
>>        1       1       1    0.06    1647    3392       0    0.66    0.00   99.28    0.00      35
>>        1       5       0    0.01    1611    3392       0    0.71
>>        2       2       0    0.02    1617    3392       0    0.50    0.02   99.46    0.00      35
>>        2       6       4    0.22    1764    3392       0    0.30
>>        3       3       4    0.25    1701    3392       0    0.07    0.00   99.68    0.00      35
>>        3       7       0    0.01    1602    3392       0    0.31
>> 20.001580 sec
>>
>>
>> So, for low loads the impact will be higher.
> 
> So it seems ondemand saves cca 1% of energy?

Yes, in this small test, on my nearly "idle" system.


Stratos

  reply	other threads:[~2014-07-21  5:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 16:59 [PATCH 0/2] cpufreq: ondemand: Eliminate the deadband effect Stratos Karafotis
2014-06-30 16:59 ` [PATCH 1/2] cpufreq: Introduce new relation for freq selection Stratos Karafotis
2014-06-30 16:59 ` [PATCH 2/2] cpufreq: ondemand: Eliminate the deadband effect Stratos Karafotis
2014-07-11 16:57   ` Pavel Machek
2014-07-11 17:29     ` Stratos Karafotis
2014-07-11 18:34       ` Pavel Machek
2014-07-11 19:37         ` Stratos Karafotis
2014-07-20 21:51           ` Pavel Machek
2014-07-21  5:41             ` Stratos Karafotis [this message]
2014-07-12 15:45 ` [PATCH 0/2] " Doug Smythies
2014-07-12 15:45   ` Doug Smythies
2014-07-13 16:54   ` Stratos Karafotis
2014-07-22 23:50 ` Rafael J. Wysocki
2014-07-23  9:01   ` Stratos Karafotis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CCA826.1070809@semaphore.gr \
    --to=stratosk@semaphore.gr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.