All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Juri Lelli <juri.lelli@redhat.com>,
	Morten Rasmussen <Morten.Rasmussen@arm.com>,
	viresh kumar <viresh.kumar@linaro.org>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Quentin Perret <quentin.perret@arm.com>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v6 03/11] sched/rt: add rt_rq utilization tracking
Date: Fri, 15 Jun 2018 14:18:07 +0200	[thread overview]
Message-ID: <CAKfTPtBHL0PEhqvpjH2wQmi7SasHyB0UfJsTQFx6e-3rAiDoVA@mail.gmail.com> (raw)
In-Reply-To: <00f701a4-8ea6-82cb-6c76-5597ffcc9f11@arm.com>

Hi Dietmar,

On 15 June 2018 at 13:52, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
> On 06/08/2018 02:09 PM, Vincent Guittot wrote:
>> schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs
>> tasks are running. When the CPU is overloaded by cfs and rt tasks, cfs tasks
>> are preempted by rt tasks and in this case util_avg reflects the remaining
>> capacity but not what cfs want to use. In such case, schedutil can select a
>> lower OPP whereas the CPU is overloaded. In order to have a more accurate
>> view of the utilization of the CPU, we track the utilization of rt tasks.
>>
>> rt_rq uses rq_clock_task and cfs_rq uses cfs_rq_clock_task but they are
>> the same at the root group level, so the PELT windows of the util_sum are
>> aligned.
>>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>
> [...]
>
> ;
>> diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
>> index 4174582..81c0d7e 100644
>> --- a/kernel/sched/pelt.c
>> +++ b/kernel/sched/pelt.c
>> @@ -307,3 +307,25 @@ int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq)
>>
>>       return 0;
>>   }
>> +
>> +/*
>> + * rt_rq:
>> + *
>> + *   util_sum = \Sum se->avg.util_sum but se->avg.util_sum is not tracked
>> + *   util_sum = cpu_scale * load_sum
>> + *   runnable_load_sum = load_sum
>> + *
>> + */
>> +
>> +int update_rt_rq_load_avg(u64 now, struct rq *rq, int running)
>> +{
>> +     if (___update_load_sum(now, rq->cpu, &rq->avg_rt,
>> +                             running,
>> +                             running,
>> +                             running)) {
>
> The patch clearly says that this is about utilization but what happens
> to load and runnable load for the rt rq part when you call
> ___update_load_sum() with load=[0,1] and runnable=[0,1]?

I would say the same than what happens for se which has
___update_load_sum(now, cpu, &se->avg, !!se->on_rq, !!se->on_rq,
cfs_rq->curr == se))

>
> It looks like that the math would require 1024 instead of 1 for load and
> runnable so that we would see a load_avg or runnable_load_avg != 0.

why does it require 1024 ? the min  weight of a task is 15 and the min
share of a sched group is 2. AFAICT, there is no requirement mainly
because we are not using them as they will not give any additional
information compare to util_avg

>
> 1594.075128: bprint: update_rt_rq_load_avg: now=1593937228087 cpu=4 running=1
> 1594.075129: bprint: update_rt_rq_load_avg: delta=3068 cpu=4 load=1 runnable=1 running=1 scale_freq=1024 scale_cpu=1024 periods=2
> 1594.075130: bprint: update_rt_rq_load_avg: load_sum=23927 +2879 runnable_load_sum=23927 +2879 util_sum=24506165 +2948096
> 1594.075130: bprint: update_rt_rq_load_avg: load_avg=0 runnable_load_avg=0 util_avg=513
>
> IMHO, the patch should say whether load and runnable load are supported as well or not.

Although it is stated that we track only utilization , i can probably
mentioned clearly that load_avg and runnable_load_avg are useless

Vincent
>
> [...]

  reply	other threads:[~2018-06-15 12:18 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-08 12:09 [PATCH v6 00/11] track CPU utilization Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 01/11] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 02/11] sched/pelt: remove blank line Vincent Guittot
2018-06-21 14:33   ` Peter Zijlstra
2018-06-21 18:42     ` Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 03/11] sched/rt: add rt_rq utilization tracking Vincent Guittot
2018-06-15 11:52   ` Dietmar Eggemann
2018-06-15 12:18     ` Vincent Guittot [this message]
2018-06-15 14:55       ` Dietmar Eggemann
2018-06-21 18:50   ` Peter Zijlstra
2018-06-08 12:09 ` [PATCH v6 04/11] cpufreq/schedutil: use rt " Vincent Guittot
2018-06-18  9:00   ` Dietmar Eggemann
2018-06-18 12:58     ` Vincent Guittot
2018-06-21 18:45   ` Peter Zijlstra
2018-06-21 18:57     ` Peter Zijlstra
2018-06-22  8:10       ` Vincent Guittot
2018-06-22 11:41         ` Peter Zijlstra
2018-06-22 12:14           ` Vincent Guittot
2018-06-22  7:58     ` Juri Lelli
2018-06-22  7:58     ` Quentin Perret
2018-06-22 11:37       ` Peter Zijlstra
2018-06-22 11:44         ` Peter Zijlstra
2018-06-22 12:23         ` Vincent Guittot
2018-06-22 13:26           ` Peter Zijlstra
2018-06-22 13:52             ` Peter Zijlstra
2018-06-22 13:54             ` Vincent Guittot
2018-06-22 13:57               ` Vincent Guittot
2018-06-22 14:46                 ` Peter Zijlstra
2018-06-22 14:49                   ` Vincent Guittot
2018-06-22 14:11               ` Peter Zijlstra
2018-06-22 14:48                 ` Peter Zijlstra
2018-06-22 14:12               ` Vincent Guittot
2018-06-22 12:54         ` Quentin Perret
2018-06-22 13:29           ` Peter Zijlstra
2018-06-22 15:22         ` Peter Zijlstra
2018-06-22 15:30           ` Quentin Perret
2018-06-22 17:24           ` Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 05/11] sched/dl: add dl_rq " Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 06/11] cpufreq/schedutil: use dl " Vincent Guittot
2018-06-08 12:39   ` Juri Lelli
2018-06-08 12:48     ` Vincent Guittot
2018-06-08 12:54       ` Juri Lelli
2018-06-08 13:36         ` Juri Lelli
2018-06-08 13:38           ` Vincent Guittot
2018-06-22 15:24   ` Peter Zijlstra
2018-06-22 17:22     ` Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 07/11] sched/irq: add irq " Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 08/11] cpufreq/schedutil: take into account interrupt Vincent Guittot
2018-06-12  8:54   ` Dietmar Eggemann
2018-06-12  9:10     ` Vincent Guittot
2018-06-12  9:16       ` Vincent Guittot
2018-06-12  9:20         ` Quentin Perret
2018-06-12  9:26           ` Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 09/11] sched: use pelt for scale_rt_capacity() Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 10/11] sched: remove rt_avg code Vincent Guittot
2018-06-08 12:09 ` [PATCH v6 11/11] proc/sched: remove unused sched_time_avg_ms Vincent Guittot

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=CAKfTPtBHL0PEhqvpjH2wQmi7SasHyB0UfJsTQFx6e-3rAiDoVA@mail.gmail.com \
    --to=vincent.guittot@linaro.org \
    --cc=Morten.Rasmussen@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=quentin.perret@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=valentin.schneider@arm.com \
    --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.