All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Abeni <luca.abeni@unitn.it>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Steve Muckle <steve.muckle@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Juri Lelli <Juri.Lelli@arm.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Michael Turquette <mturquette@baylibre.com>
Subject: Re: [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity
Date: Fri, 11 Dec 2015 08:48:34 +0100	[thread overview]
Message-ID: <566A7FD2.4050601@unitn.it> (raw)
In-Reply-To: <CAKfTPtC2bcdO=KKxsF71fF8tMtAxhR8OZQpqZ0m0ce-D=nnNfQ@mail.gmail.com>

Hi Vincent,

On 12/10/2015 05:11 PM, Vincent Guittot wrote:
[...]
>> If yes, I think your approach is safe (and easier to implement - modulo a
>> small
>> issue when a task terminates of switches to other scheduling policies; I
>> think
>> there already are some "XXX" comments in the current code). However, it
>> allows to
>> save less energy (or reclaim less CPU time). For example, if I create a
>> SCHED_DEADLINE
>> task with runtime 90ms and period 100ms it will not allow to scale the CPU
>> frequency
>> even if it never executes (because is always blocked).
>
> Yes, i agree. If the task behavior is not aligned with its deadline
> parameters, we will over provisioned CPU capacity to the deadline
> scheduler.
> This metric is not used to select the OPP but to provisioned some CPU
> capacity to the deadline scheduler and to inform the CFS scheduler of
> the remaining capacity.
Ah, sorry; I missed this point.


>>>> +       /* This is the "average utilization" for this runqueue */
>>>> +       s64 avg_bw;
>>>>    };
>>
>> Small nit: why "average" utilization? I think a better name would be
>> "runqueue utilization"
>> or "local utilization", or something similar... If I understand correctly
>> (sorry if I
>> missed something), this is not an average, but the sum of the utilisations
>> of the tasks
>> on this runqueue... No?
>
> I have used "average" because it doesn't reflect the active/actual
> utilization of the run-queue but the forecasted average bandwidth of
> the CPU that will be used by deadline task.
Well, this is just nitpicking, so feel free to ignore (I just mentioned
this point because I was initially confused by the "average" name). But I
think this is "maximum", or "worst-case", not "average", because (as far
as I can understand) this field indicates that SCHED_DEADLINE tasks will
not be able to consume more than this fraction of CPU (if they try to
consume more, the scheduler throttles them).

> I'm open to change the name if another one makes more sense
In real-time literature this is often called simply "utilization" (or "worst-case
utilization" by someone): when a task can have a variable execution time, its
utilization is defined as WCET (maximum execution time) / period.



				Luca

  reply	other threads:[~2015-12-11  7:48 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09  6:19 [RFCv6 PATCH 00/10] sched: scheduler-driven CPU frequency selection Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 01/10] sched: Compute cpu capacity available at current frequency Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 02/10] cpufreq: introduce cpufreq_driver_is_slow Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection Steve Muckle
2015-12-11 11:04   ` Juri Lelli
2015-12-15  2:02     ` Steve Muckle
2015-12-15 10:31       ` Juri Lelli
2015-12-16  1:22         ` Steve Muckle
2015-12-16  3:48   ` Leo Yan
2015-12-17  1:24     ` Steve Muckle
2015-12-17  7:17       ` Leo Yan
2015-12-18 19:15         ` Steve Muckle
2015-12-19  5:54           ` Leo Yan
2016-01-25 12:06   ` Ricky Liang
2016-01-27  1:14     ` Steve Muckle
2016-02-01 17:10   ` Ricky Liang
2016-02-11  4:44     ` Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 04/10] sched/fair: add triggers for OPP change requests Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 05/10] sched/{core,fair}: trigger OPP change request on fork() Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 06/10] sched/fair: cpufreq_sched triggers for load balancing Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 07/10] sched/fair: jump to max OPP when crossing UP threshold Steve Muckle
2015-12-11 11:12   ` Juri Lelli
2015-12-15  2:42     ` Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 08/10] sched: remove call of sched_avg_update from sched_rt_avg_update Steve Muckle
2015-12-09  6:19 ` [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity Steve Muckle
2015-12-09  8:50   ` Vincent Guittot
2015-12-10 13:27     ` Luca Abeni
2015-12-10 16:11       ` Vincent Guittot
2015-12-11  7:48         ` Luca Abeni [this message]
2015-12-14 14:02           ` Vincent Guittot
2015-12-14 14:38             ` Luca Abeni
2015-12-14 15:17   ` Peter Zijlstra
2015-12-14 15:56     ` Vincent Guittot
2015-12-14 16:07       ` Juri Lelli
2015-12-14 21:19         ` Luca Abeni
2015-12-14 16:51       ` Peter Zijlstra
2015-12-14 21:31         ` Luca Abeni
2015-12-15 12:38           ` Peter Zijlstra
2015-12-15 13:30             ` Luca Abeni
2015-12-15 13:42               ` Peter Zijlstra
2015-12-15 21:24                 ` Luca Abeni
2015-12-16  9:28                   ` Juri Lelli
2015-12-15  4:43         ` Vincent Guittot
2015-12-15 12:41           ` Peter Zijlstra
2015-12-15 12:56             ` Vincent Guittot
2015-12-14 21:12       ` Luca Abeni
2015-12-15  4:59         ` Vincent Guittot
2015-12-15  8:50           ` Luca Abeni
2015-12-15 12:20             ` Peter Zijlstra
2015-12-15 12:46               ` Vincent Guittot
2015-12-15 13:18               ` Luca Abeni
2015-12-15 12:23             ` Peter Zijlstra
2015-12-15 13:21               ` Luca Abeni
2015-12-15 12:43             ` Vincent Guittot
2015-12-15 13:39               ` Luca Abeni
2015-12-15 12:58             ` Vincent Guittot
2015-12-15 13:41               ` Luca Abeni
2015-12-09  6:19 ` [RFCv6 PATCH 10/10] sched: rt scheduler sets capacity requirement Steve Muckle
2015-12-11 11:22   ` Juri Lelli

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=566A7FD2.4050601@unitn.it \
    --to=luca.abeni@unitn.it \
    --cc=Juri.Lelli@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --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 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.