From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Michael Turquette <mturquette@baylibre.com>,
peterz@infradead.org, rjw@rjwysocki.net
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Juri.Lelli@arm.com, steve.muckle@linaro.org,
morten.rasmussen@arm.com, vincent.guittot@linaro.org,
Michael Turquette <mturquette+renesas@baylibre.com>
Subject: Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support
Date: Wed, 16 Mar 2016 18:33:55 +0000 [thread overview]
Message-ID: <56E9A713.4030007@arm.com> (raw)
In-Reply-To: <20160315201917.30639.2415@quark.deferred.io>
On 15/03/16 20:19, Michael Turquette wrote:
> Quoting Dietmar Eggemann (2016-03-15 12:13:46)
>> Hi Mike,
>>
>> On 14/03/16 05:22, Michael Turquette wrote:
>>> From: Dietmar Eggemann <dietmar.eggemann@arm.com>
>>>
[...]
>> Maybe it is worth mentioning that this patch is from EAS RFC5.2
>> (linux-arm.org/linux-power.git energy_model_rfc_v5.2) which hasn't been
>> posted to LKML. The last EAS RFCv5 has the Frequency Invariant Engine
>> (FEI) based on the cpufreq notifier calls (cpufreq_callback,
>> cpufreq_policy_callback) in the ARM arch code.
>
> Oops, my apologies. I got a little mixed up while developing these
> patches and I should have at least asked you about this one before
> posting.
No need to apologize, just wanted to set the context right for people
following the EAS stuff.
> I'm really quite happy to drop #7 and #8 if they are too contentious or
> if patch #7 is deemed as not-ready by you.
If people think that driving frequency invariance from within cpufreq.c
is the right thing to so then this patch can stay.
That said, I'm not sure if we can do a better job of integrating
freq_scale into existing cpufreq data structures.
>>> If run-time selection of ops is needed them someone will need to write
>>> that code.
>>
>> Right now I see 3 different implementations of the FEI. 1) The X86
>> aperf/mperf based one (https://lkml.org/lkml/2016/3/3/589), 2) This one
>> in cpufreq.c and 3) the one based on cpufreq notifiers in ARCH (ARM,
>> ARM64) code.
I rechecked the functionality of this implementation (2) versus (1) and
(3) by running them all together on an X86 system w/
X86_FEATURE_APERFMPERF and acpi-cpufreq (i5 CPU M520) w/o actually doing
the wiring towards arch_scale_freq_capacity and they all behave similar
or equal. The update of (1) happens much more often obviously since its
driven from the scheduler tick.
...
arch_scale_freq_tick: APERF/MPERF: aperf=5864236223 mperf=6009442434
acnt=200073 mcnt=362360 arch_cpu_freq=565
arch_scale_freq_tick: APERF/MPERF: aperf=5864261886 mperf=6009474724
acnt=25663 mcnt=32290 arch_cpu_freq=813
scale_freq_capacity: CPUFREQ.C: cpu=1 freq_scale=910
cpufreq_callback: NOTIFIER: cpu=1 curr_freq=2133000 max_freq=2400000
freq_scale=910
arch_scale_freq_tick: APERF/MPERF: aperf=5864524610 mperf=6009802492
acnt=262724 mcnt=327768 arch_cpu_freq=820
arch_scale_freq_tick: APERF/MPERF: aperf=5864581063 mperf=6009862268
acnt=56453 mcnt=59776 arch_cpu_freq=967
...
[...]
next prev parent reply other threads:[~2016-03-16 18:34 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 5:22 [PATCH 0/8] schedutil enhancements Michael Turquette
2016-03-14 5:22 ` [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update() Michael Turquette
2016-03-15 21:14 ` Peter Zijlstra
[not found] ` <20160315214545.30639.98727@quark.deferred.io>
2016-03-15 21:49 ` Peter Zijlstra
2016-03-16 8:00 ` Peter Zijlstra
2016-03-14 5:22 ` [PATCH 2/8] sched/fair: add margin to utilization update Michael Turquette
2016-03-15 21:16 ` Peter Zijlstra
[not found] ` <20160315212848.30639.38747@quark.deferred.io>
2016-03-15 21:43 ` Peter Zijlstra
2016-03-16 2:52 ` Steve Muckle
2016-03-16 22:12 ` Michael Turquette
2016-03-14 5:22 ` [PATCH 3/8] sched/cpufreq: new cfs capacity margin helpers Michael Turquette
2016-03-15 21:17 ` Peter Zijlstra
2016-03-14 5:22 ` [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable Michael Turquette
2016-03-15 21:20 ` Peter Zijlstra
[not found] ` <20160315214043.30639.75507@quark.deferred.io>
2016-03-15 21:48 ` Peter Zijlstra
[not found] ` <20160315223701.30639.43127@quark.deferred.io>
2016-03-16 3:36 ` Steve Muckle
2016-03-16 8:05 ` Peter Zijlstra
2016-03-16 10:02 ` Juri Lelli
2016-03-16 17:55 ` Steve Muckle
2016-03-16 22:05 ` Michael Turquette
2016-03-17 9:40 ` Juri Lelli
2016-03-17 13:55 ` Steve Muckle
2016-03-17 15:53 ` Patrick Bellasi
2016-03-17 17:54 ` Juri Lelli
2016-03-17 18:56 ` Michael Turquette
2016-03-17 22:34 ` Rafael J. Wysocki
2016-03-16 12:45 ` Rafael J. Wysocki
2016-03-16 22:03 ` Michael Turquette
2016-03-14 5:22 ` [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util Michael Turquette
2016-03-15 21:25 ` Peter Zijlstra
[not found] ` <20160315220609.30639.67271@quark.deferred.io>
2016-03-16 3:55 ` Steve Muckle
2016-03-16 7:41 ` Peter Zijlstra
2016-03-16 8:29 ` Vincent Guittot
2016-03-16 8:53 ` Peter Zijlstra
2016-03-16 9:16 ` Vincent Guittot
2016-03-16 12:39 ` Rafael J. Wysocki
2016-03-16 13:10 ` Peter Zijlstra
2016-03-16 13:23 ` Rafael J. Wysocki
2016-03-16 13:43 ` Peter Zijlstra
2016-03-14 5:22 ` [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization Michael Turquette
2016-03-15 21:29 ` Peter Zijlstra
[not found] ` <20160315220951.30639.12872@quark.deferred.io>
2016-03-16 7:38 ` Peter Zijlstra
2016-03-16 18:20 ` Steve Muckle
2016-03-16 18:36 ` Peter Zijlstra
2016-03-16 19:12 ` Steve Muckle
2016-03-14 5:22 ` [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support Michael Turquette
2016-03-15 19:13 ` Dietmar Eggemann
2016-03-15 20:19 ` Michael Turquette
2016-03-15 21:32 ` Peter Zijlstra
2016-03-16 18:33 ` Dietmar Eggemann [this message]
2016-03-15 21:34 ` Peter Zijlstra
2016-03-14 5:22 ` [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity Michael Turquette
2016-03-15 19:13 ` Dietmar Eggemann
2016-03-15 20:46 ` Michael Turquette
2016-03-16 19:44 ` Dietmar Eggemann
2016-03-16 20:07 ` Peter Zijlstra
2016-03-16 21:32 ` Rafael J. Wysocki
2016-03-15 21:37 ` Peter Zijlstra
[not found] ` <20160315222721.30639.28332@quark.deferred.io>
2016-03-16 7:47 ` Peter Zijlstra
2016-03-16 12:41 ` Peter Zijlstra
2016-03-16 0:08 ` [PATCH 0/8] schedutil enhancements Rafael J. Wysocki
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=56E9A713.4030007@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=Juri.Lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=mturquette+renesas@baylibre.com \
--cc=mturquette@baylibre.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=steve.muckle@linaro.org \
--cc=vincent.guittot@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