[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfTPtAegZKuGoLv0PTRV8J9Bz8Qz3=xtAtkjfnv5_jFOn8u6g@mail.gmail.com>
Date: Thu, 24 Oct 2019 16:00:02 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Patrick Bellasi <patrick.bellasi@...bug.net>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
"open list:THERMAL" <linux-pm@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Douglas Raillard <douglas.raillard@....com>,
Quentin Perret <qperret@...gle.com>,
Patrick Bellasi <patrick.bellasi@...bug.com>
Subject: Re: [PATCH v2] sched/fair: util_est: fast ramp-up EWMA on utilization increases
On Wed, 23 Oct 2019 at 22:56, Patrick Bellasi
<patrick.bellasi@...bug.net> wrote:
>
> The estimated utilization for a task:
>
> util_est = max(util_avg, est.enqueue, est.ewma)
>
> is defined based on:
> - util_avg: the PELT defined utilization
> - est.enqueued: the util_avg at the end of the last activation
> - est.ewma: a exponential moving average on the est.enqueued
> samples
>
> According to this definition, when a task suddenly change its bandwidth
> requirements from small to big, the EWMA will need to collect multiple
> samples before converging up to track the new big utilization.
>
> This slow convergence towards bigger utilization values is not
> aligned to the default scheduler behavior, which is to optimize for
> performance. Moreover, the est.ewma component fails to compensate for
> temporarely utilization drops which spans just few est.enqueued samples.
>
> To let util_est do a better job in the scenario depicted above, change
> its definition by making util_est directly follow upward motion and
> only decay the est.ewma on downward.
>
> Signed-off-by: Patrick Bellasi <patrick.bellasi@...bug.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
Acked-by: Vincent Guittot <vincent.guittot@...aro.org>
> ---
> kernel/sched/fair.c | 14 +++++++++++++-
> kernel/sched/features.h | 1 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a81c36472822..a14487462b6c 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3768,11 +3768,22 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct task_struct *p, bool task_sleep)
> if (ue.enqueued & UTIL_AVG_UNCHANGED)
> return;
>
> + /*
> + * Reset EWMA on utilization increases, the moving average is used only
> + * to smooth utilization decreases.
> + */
> + ue.enqueued = (task_util(p) | UTIL_AVG_UNCHANGED);
> + if (sched_feat(UTIL_EST_FASTUP)) {
> + if (ue.ewma < ue.enqueued) {
> + ue.ewma = ue.enqueued;
> + goto done;
> + }
> + }
> +
> /*
> * Skip update of task's estimated utilization when its EWMA is
> * already ~1% close to its last activation value.
> */
> - ue.enqueued = (task_util(p) | UTIL_AVG_UNCHANGED);
> last_ewma_diff = ue.enqueued - ue.ewma;
> if (within_margin(last_ewma_diff, (SCHED_CAPACITY_SCALE / 100)))
> return;
> @@ -3805,6 +3816,7 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct task_struct *p, bool task_sleep)
> ue.ewma <<= UTIL_EST_WEIGHT_SHIFT;
> ue.ewma += last_ewma_diff;
> ue.ewma >>= UTIL_EST_WEIGHT_SHIFT;
> +done:
> WRITE_ONCE(p->se.avg.util_est, ue);
> }
>
> diff --git a/kernel/sched/features.h b/kernel/sched/features.h
> index 2410db5e9a35..7481cd96f391 100644
> --- a/kernel/sched/features.h
> +++ b/kernel/sched/features.h
> @@ -89,3 +89,4 @@ SCHED_FEAT(WA_BIAS, true)
> * UtilEstimation. Use estimated CPU utilization.
> */
> SCHED_FEAT(UTIL_EST, true)
> +SCHED_FEAT(UTIL_EST_FASTUP, true)
> --
> 2.17.1
>
Powered by blists - more mailing lists