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
next prev parent 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.