From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
peterz@infradead.org, mingo@kernel.org,
linux-kernel@vger.kernel.org, rjw@rjwysocki.net
Cc: juri.lelli@redhat.com, Morten.Rasmussen@arm.com,
viresh.kumar@linaro.org, valentin.schneider@arm.com,
quentin.perret@arm.com
Subject: Re: [PATCH v5 07/10] sched/irq: add irq utilization tracking
Date: Wed, 30 May 2018 17:55:24 +0200 [thread overview]
Message-ID: <72473e6f-8ade-8e26-3282-276fcae4c4c7@arm.com> (raw)
In-Reply-To: <1527253951-22709-8-git-send-email-vincent.guittot@linaro.org>
On 05/25/2018 03:12 PM, Vincent Guittot wrote:
> interrupt and steal time are the only remaining activities tracked by
> rt_avg. Like for sched classes, we can use PELT to track their average
> utilization of the CPU. But unlike sched class, we don't track when
> entering/leaving interrupt; Instead, we take into account the time spent
> under interrupt context when we update rqs' clock (rq_clock_task).
> This also means that we have to decay the normal context time and account
> for interrupt time during the update.
>
> That's also important to note that because
> rq_clock == rq_clock_task + interrupt time
> and rq_clock_task is used by a sched class to compute its utilization, the
> util_avg of a sched class only reflects the utilization of the time spent
> in normal context and not of the whole time of the CPU. The utilization of
> interrupt gives an more accurate level of utilization of CPU.
> The CPU utilization is :
> avg_irq + (1 - avg_irq / max capacity) * /Sum avg_rq
>
> Most of the time, avg_irq is small and neglictible so the use of the
> approximation CPU utilization = /Sum avg_rq was enough
[...]
> @@ -7362,6 +7363,7 @@ static void update_blocked_averages(int cpu)
> }
> update_rt_rq_load_avg(rq_clock_task(rq), rq, 0);
> update_dl_rq_load_avg(rq_clock_task(rq), rq, 0);
> + update_irq_load_avg(rq, 0);
So this one decays the signals only in case the update_rq_clock_task()
didn't call update_irq_load_avg() because 'irq_delta + steal' is 0, right?
[...]
> diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
> index 3d5bd3a..d2e4f21 100644
> --- a/kernel/sched/pelt.c
> +++ b/kernel/sched/pelt.c
> @@ -355,3 +355,41 @@ int update_dl_rq_load_avg(u64 now, struct rq *rq, int running)
>
> return 0;
> }
> +
> +/*
> + * irq:
> + *
> + * 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_irq_load_avg(struct rq *rq, u64 running)
> +{
> + int ret = 0;
> + /*
> + * We know the time that has been used by interrupt since last update
> + * but we don't when. Let be pessimistic and assume that interrupt has
> + * happened just before the update. This is not so far from reality
> + * because interrupt will most probably wake up task and trig an update
> + * of rq clock during which the metric si updated.
> + * We start to decay with normal context time and then we add the
> + * interrupt context time.
> + * We can safely remove running from rq->clock because
> + * rq->clock += delta with delta >= running
This is true as long update_irq_load_avg() with a 'running != 0' is
called only after rq->clock moved forward (rq->clock += delta) (which is
true for update_rq_clock()->update_rq_clock_task()).
> + */
> + ret = ___update_load_sum(rq->clock - running, rq->cpu, &rq->avg_irq,
> + 0,
> + 0,
> + 0);
> + ret += ___update_load_sum(rq->clock, rq->cpu, &rq->avg_irq,
> + 1,
> + 1,
> + 1);
So you decay the signal in [sa->lut, rq->clock - running] (assumed to be
the portion of delta used by the task scheduler) and you increase it in
[rq->clock - running, rq->clock] (irq and virt portion of delta).
That means that this signal is updated on rq->clock whereas the others
are on rq->clock_task.
What about the ever growing clock diff between them? I see e.g ~6s after
20min uptime and up to 1.5ms 'running'.
It should be still safe to sum the sched class and irq signal in
sugov_aggregate_util() because they are independent, I guess.
[...]
next prev parent reply other threads:[~2018-05-30 15:55 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 13:12 [PATCH v5 00/10] track CPU utilization Vincent Guittot
2018-05-25 13:12 ` [PATCH v5 01/10] sched/pelt: Move pelt related code in a dedicated file Vincent Guittot
2018-05-25 14:26 ` Quentin Perret
2018-05-25 16:14 ` Peter Zijlstra
2018-05-29 8:21 ` Quentin Perret
2018-05-25 18:04 ` Patrick Bellasi
2018-05-29 14:55 ` Quentin Perret
2018-05-29 15:02 ` Vincent Guittot
2018-05-29 15:04 ` Quentin Perret
2018-05-25 13:12 ` [PATCH v5 02/10] sched/rt: add rt_rq utilization tracking Vincent Guittot
2018-05-25 15:54 ` Patrick Bellasi
2018-05-29 13:29 ` Vincent Guittot
2018-05-30 9:32 ` Patrick Bellasi
2018-05-30 10:06 ` Vincent Guittot
2018-05-30 11:01 ` Patrick Bellasi
2018-05-30 14:39 ` Vincent Guittot
2018-05-25 13:12 ` [PATCH v5 03/10] cpufreq/schedutil: add rt " Vincent Guittot
2018-05-30 7:03 ` Viresh Kumar
2018-05-30 8:23 ` Vincent Guittot
2018-05-30 9:40 ` Patrick Bellasi
2018-05-30 9:53 ` Vincent Guittot
2018-05-30 16:46 ` Quentin Perret
2018-05-31 8:46 ` Juri Lelli
2018-06-01 16:23 ` Peter Zijlstra
2018-06-01 17:23 ` Patrick Bellasi
2018-06-04 10:17 ` Quentin Perret
2018-06-04 15:16 ` Patrick Bellasi
2018-05-25 13:12 ` [PATCH v5 04/10] sched/dl: add dl_rq " Vincent Guittot
2018-05-30 10:50 ` Patrick Bellasi
2018-05-30 11:51 ` Vincent Guittot
2018-05-25 13:12 ` [PATCH v5 05/10] cpufreq/schedutil: get max utilization Vincent Guittot
2018-05-28 10:12 ` Juri Lelli
2018-05-28 14:57 ` Vincent Guittot
2018-05-28 15:22 ` Juri Lelli
2018-05-28 16:34 ` Vincent Guittot
2018-05-31 10:27 ` Patrick Bellasi
2018-05-31 13:02 ` Vincent Guittot
2018-06-01 13:53 ` Vincent Guittot
2018-06-01 17:45 ` Joel Fernandes
2018-06-04 6:41 ` Vincent Guittot
2018-06-04 7:04 ` Juri Lelli
2018-06-04 7:14 ` Vincent Guittot
2018-06-04 10:12 ` Juri Lelli
2018-06-04 12:35 ` Vincent Guittot
2018-05-29 5:08 ` Joel Fernandes
2018-05-29 6:31 ` Juri Lelli
2018-05-29 6:48 ` Vincent Guittot
2018-05-29 9:47 ` Juri Lelli
2018-05-29 8:40 ` Quentin Perret
2018-05-29 9:52 ` Juri Lelli
2018-05-30 8:37 ` Quentin Perret
2018-05-30 8:51 ` Juri Lelli
2018-05-25 13:12 ` [PATCH v5 06/10] sched: remove rt and dl from sched_avg Vincent Guittot
2018-05-25 13:12 ` [PATCH v5 07/10] sched/irq: add irq utilization tracking Vincent Guittot
2018-05-30 15:55 ` Dietmar Eggemann [this message]
2018-05-30 18:45 ` Vincent Guittot
2018-05-31 16:54 ` Dietmar Eggemann
2018-06-06 16:06 ` Vincent Guittot
2018-06-07 8:29 ` Dietmar Eggemann
2018-06-07 8:44 ` Vincent Guittot
2018-06-07 9:06 ` Dietmar Eggemann
2018-05-25 13:12 ` [PATCH v5 08/10] cpufreq/schedutil: take into account interrupt Vincent Guittot
2018-05-28 10:41 ` Juri Lelli
2018-05-28 12:06 ` Vincent Guittot
2018-05-28 12:37 ` Juri Lelli
2018-05-25 13:12 ` [PATCH v5 09/10] sched: remove rt_avg code Vincent Guittot
2018-05-25 13:12 ` [PATCH v5 10/10] proc/sched: remove unused sched_time_avg_ms Vincent Guittot
2018-06-04 16:50 ` [PATCH v5 00/10] track CPU utilization Peter Zijlstra
2018-06-04 17:13 ` Quentin Perret
2018-06-04 18:08 ` Vincent Guittot
2018-06-05 14:18 ` Peter Zijlstra
2018-06-05 15:03 ` Juri Lelli
2018-06-05 15:38 ` Patrick Bellasi
2018-06-05 22:27 ` Peter Zijlstra
2018-06-06 9:44 ` Quentin Perret
2018-06-06 9:59 ` Vincent Guittot
2018-06-06 10:02 ` Vincent Guittot
2018-06-06 10:12 ` Quentin Perret
2018-06-05 8:36 ` Vincent Guittot
2018-06-05 10:57 ` Quentin Perret
2018-06-05 11:59 ` Vincent Guittot
2018-06-05 13:12 ` Quentin Perret
2018-06-05 13:18 ` Vincent Guittot
2018-06-05 13:52 ` Quentin Perret
2018-06-05 13:55 ` Vincent Guittot
2018-06-05 14:09 ` Quentin Perret
2018-06-05 14:21 ` Quentin Perret
2018-06-05 12:11 ` Juri Lelli
2018-06-05 13:05 ` Quentin Perret
2018-06-05 13:15 ` Juri Lelli
2018-06-05 14:01 ` Quentin Perret
2018-06-05 14:13 ` Juri Lelli
2018-06-06 13:05 ` Claudio Scordino
2018-06-06 13:20 ` Quentin Perret
2018-06-06 13:53 ` Claudio Scordino
2018-06-06 14:10 ` Quentin Perret
2018-06-06 21:05 ` luca abeni
2018-06-07 8:25 ` Quentin Perret
2018-06-06 20:53 ` luca abeni
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=72473e6f-8ade-8e26-3282-276fcae4c4c7@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=Morten.Rasmussen@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=quentin.perret@arm.com \
--cc=rjw@rjwysocki.net \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
--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;
as well as URLs for NNTP newsgroup(s).