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: Fri, 11 Jul 2014 20:29:57 +0300 [thread overview]
Message-ID: <53C01F15.2090702@semaphore.gr> (raw)
In-Reply-To: <20140711165710.GA18033@amd.pavel.ucw.cz>
Hi Pavel!
On 11/07/2014 07:57 μμ, 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.
On my tests, a simple mp3 decoding (very low load on my machine) have no
difference with and without this patch.
> So... should we do that, or do we need better benchmark?
I'm sorry. I'm not sure I understood exactly what do you mean by "better
benchmark".
Of course, we should do as many benchmarks as we can.
I usually do these 5 sets of benchmarks on my i7 that IMHO give a good
indication about the changes in different CPU loads.
1) Linux kernel compilation (about 85% busy CPU)
2) Apache (about 32% busy CPU)
3) ffmpeg (about 24% busy CPU)
4) mp3 decoding (about 0.3% CPU)
5) Idle system (about 0.06% CPU)
The patch was also tested on a Android smartphone (kernel 3.4). The kernel
distributed to 1000+ users.
Unfortunately I have no benchmarks, but no regressions reported on
consumption. Actually, there reports for better performance and
lower power consumption, but of course we can't rely on these reports. :)
Thanks for your comments!
Stratos
next prev parent reply other threads:[~2014-07-11 17:30 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 [this message]
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
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=53C01F15.2090702@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.