From: Borislav Petkov <bp@suse.de>
To: Stratos Karafotis <stratosk@semaphore.gr>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Viresh Kumar <viresh.kumar@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
linux-pm@vger.kernel.org, cpufreq@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] cpufreq: ondemand: Change the calculation of target frequency
Date: Wed, 5 Jun 2013 18:17:03 +0200 [thread overview]
Message-ID: <20130605161703.GA29958@pd.tnic> (raw)
In-Reply-To: <51AF60D5.3080605@semaphore.gr>
On Wed, Jun 05, 2013 at 07:01:25PM +0300, Stratos Karafotis wrote:
> Ondemand calculates load in terms of frequency and increases it only
> if the load_freq is greater than up_threshold multiplied by current
> or average frequency. This seems to produce oscillations of frequency
> between min and max because, for example, a relatively small load can
> easily saturate minimum frequency and lead the CPU to max. Then, the
> CPU will decrease back to min due to a small load_freq.
Right, and I think this is how we want it, no?
The thing is, the faster you finish your work, the faster you can become
idle and save power.
If you switch frequencies in a staircase-like manner, you're going to
take longer to finish, in certain cases, and burn more power while doing
so.
Btw, racing to idle is also a good example for why you want boosting:
you want to go max out the core but stay within power limits so that you
can finish sooner.
> This patch changes the calculation method of load and target frequency
> considering 2 points:
> - Load computation should be independent from current or average
> measured frequency. For example an absolute load 80% at 100MHz is not
> necessarily equivalent to 8% at 1000MHz in the next sampling interval.
> - Target frequency should be increased to any value of frequency table
> proportional to absolute load, instead to only the max. Thus:
>
> Target frequency = C * load
>
> where C = policy->cpuinfo.max_freq / 100
>
> Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait.
> Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an
> increase ~1.5% in performance. cpufreq_stats (time_in_state) shows
> that middle frequencies are used more, with this patch. Highest
> and lowest frequencies were used less by ~9%
I read this as "the workload takes longer to complete" which means
higher power consumption and longer execution times which means less
time spent in idle. And I don't think we want that.
Yes, no?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-06-05 16:17 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 16:01 [PATCH v3 1/3] cpufreq: ondemand: Change the calculation of target frequency Stratos Karafotis
2013-06-05 16:17 ` Borislav Petkov [this message]
2013-06-05 16:58 ` David C Niemi
2013-06-06 9:55 ` Borislav Petkov
2013-06-06 9:57 ` Viresh Kumar
2013-06-06 13:50 ` David C Niemi
2013-06-05 17:13 ` Stratos Karafotis
2013-06-05 20:35 ` Rafael J. Wysocki
2013-06-06 10:01 ` Borislav Petkov
2013-06-06 10:10 ` Viresh Kumar
2013-06-06 12:10 ` Borislav Petkov
2013-06-06 16:46 ` Stratos Karafotis
2013-06-06 17:11 ` Borislav Petkov
2013-06-06 17:32 ` Stratos Karafotis
2013-06-07 19:14 ` Stratos Karafotis
2013-06-07 20:57 ` Rafael J. Wysocki
2013-06-08 9:56 ` Stratos Karafotis
2013-06-08 11:18 ` Rafael J. Wysocki
-- strict thread matches above, loose matches on Subject: below --
2013-06-06 12:54 Stratos Karafotis
2013-06-06 13:15 ` Borislav Petkov
2013-06-06 12:56 Stratos Karafotis
2013-06-08 12:34 Stratos Karafotis
2013-06-08 14:05 ` Rafael J. Wysocki
2013-06-08 20:31 ` Stratos Karafotis
2013-06-08 22:18 ` Rafael J. Wysocki
2013-06-09 16:26 ` Borislav Petkov
2013-06-09 18:08 ` Stratos Karafotis
2013-06-09 20:58 ` Rafael J. Wysocki
2013-06-09 21:14 ` Borislav Petkov
2013-06-09 22:11 ` Rafael J. Wysocki
2013-06-10 21:57 ` Stratos Karafotis
2013-06-10 23:24 ` Rafael J. Wysocki
2013-06-13 21:22 ` Stratos Karafotis
2013-06-13 21:40 ` Borislav Petkov
2013-06-13 22:04 ` Stratos Karafotis
2013-06-13 22:38 ` Borislav Petkov
2013-06-13 22:15 ` Rafael J. Wysocki
2013-06-13 22:37 ` Borislav Petkov
2013-06-14 12:46 ` Rafael J. Wysocki
2013-06-14 12:44 ` Borislav Petkov
2013-06-14 12:55 ` Rafael J. Wysocki
2013-06-14 15:53 ` 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=20130605161703.GA29958@pd.tnic \
--to=bp@suse.de \
--cc=cpufreq@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rjw@sisk.pl \
--cc=stratosk@semaphore.gr \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox