public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Juri Lelli <Juri.Lelli@arm.com>,
	Steve Muckle <steve.muckle@linaro.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Michael Turquette <mturquette+renesas@baylibre.com>
Subject: Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util
Date: Wed, 16 Mar 2016 14:10:08 +0100	[thread overview]
Message-ID: <20160316131008.GW6344@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJZ5v0jPtobKGR01D9obxhHibz4aPrPFjmuX19zAE5a5Uz8aEQ@mail.gmail.com>

On Wed, Mar 16, 2016 at 01:39:10PM +0100, Rafael J. Wysocki wrote:
> On Wed, Mar 16, 2016 at 9:53 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Wed, Mar 16, 2016 at 09:29:59AM +0100, Vincent Guittot wrote:
> >> I wonder if it's really worth passing per sched_class request to
> >> sched_util ? sched_util is about selecting a frequency based on the
> >> utilization of the CPU, it only needs a value that reflect the whole
> >> utilization. Can't we sum  (or whatever the formula we want to apply)
> >> utilizations before calling cpufreq_update_util
> >
> > So I've thought the same; but I'm conflicted, its a shame to compute
> > anything if the call then doesn't do anything with it.
> >
> > And keeping a structure of all the various numbers to pass in also has
> > cost of yet another cacheline to touch.
> 
> In principle we can use high-order bits of util and max to encode the
> information on where they come from.
> 
> Of course, that translates to additional ifs in the governor, but I
> guess they are unavoidable anyway.

Another thing we can do, for as long as we have the indirect function
call anyway, is stuff extra pointers in that same cacheline we pull the
function from.

Something like the below; there's room for 8 pointers (including the
function pointer) in a cacheline.

That would allow the callback to fetch whatever data it feels is
required (could be all of it).

We could also put a u64 *now = &rq->clock in, which would leave another
4 pointers for DL/RT support.

And since we're then back to 1-2 arguments on the function, we can add a
flags/mask field to indicate what changed (and if the function
throttles, it can keep a mask of all that changed since last time it
actually did something, or allow punching through the throttle if our
minimum guarantee changes or whatnot).

(this would of course require we allocate struct update_util_data with
the proper alignment thingies etc..)

Then again, maybe this is somewhat overboard :-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index ba49c9efd0b2..d34d75c5cc93 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -3236,8 +3236,10 @@ static inline unsigned long rlimit_max(unsigned int limit)
 
 #ifdef CONFIG_CPU_FREQ
 struct update_util_data {
-	void (*func)(struct update_util_data *data,
-		     u64 time, unsigned long util, unsigned long max);
+	unsigned long *cfs_util_avg;
+	unsigned long *cfs_util_max;
+
+	void (*func)(struct update_util_data *data, u64 time);
 };
 
 void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c
index 928c4ba32f68..de5b20b11de3 100644
--- a/kernel/sched/cpufreq.c
+++ b/kernel/sched/cpufreq.c
@@ -32,6 +32,9 @@ void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
 	if (WARN_ON(data && !data->func))
 		return;
 
+	data->cfs_util_avg = &cpu_rq(cpu)->cfs.avg.util_avg;
+	data->cfs_util_max = &cpu_rq(cpu)->cpu_capacity_orig;
+
 	rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
 }
 EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);

  reply	other threads:[~2016-03-16 13:10 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 [this message]
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
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=20160316131008.GW6344@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Juri.Lelli@arm.com \
    --cc=dietmar.eggemann@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=rafael@kernel.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