From: Patrick Bellasi <patrick.bellasi@arm.com>
To: Pavan Kondeti <pkondeti@codeaurora.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Paul Turner <pjt@google.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Juri Lelli <juri.lelli@redhat.com>, Todd Kjos <tkjos@android.com>,
Joel Fernandes <joelaf@google.com>,
Steve Muckle <smuckle@google.com>
Subject: Re: [PATCH v3 2/3] sched/fair: use util_est in LB and WU paths
Date: Wed, 31 Jan 2018 15:32:23 +0000 [thread overview]
Message-ID: <20180131153223.GD5739@e110439-lin> (raw)
In-Reply-To: <20180125143358.GE30677@codeaurora.org>
On 25-Jan 20:03, Pavan Kondeti wrote:
> On Wed, Jan 24, 2018 at 07:31:38PM +0000, Patrick Bellasi wrote:
> >
> > > > + /*
> > > > + * These are the main cases covered:
> > > > + * - if *p is the only task sleeping on this CPU, then:
> > > > + * cpu_util (== task_util) > util_est (== 0)
> > > > + * and thus we return:
> > > > + * cpu_util_wake = (cpu_util - task_util) = 0
> > > > + *
> > > > + * - if other tasks are SLEEPING on the same CPU, which is just waking
> > > > + * up, then:
> > > > + * cpu_util >= task_util
> > > > + * cpu_util > util_est (== 0)
> > > > + * and thus we discount *p's blocked utilization to return:
> > > > + * cpu_util_wake = (cpu_util - task_util) >= 0
> > > > + *
> > > > + * - if other tasks are RUNNABLE on that CPU and
> > > > + * util_est > cpu_util
> > > > + * then we use util_est since it returns a more restrictive
> > > > + * estimation of the spare capacity on that CPU, by just considering
> > > > + * the expected utilization of tasks already runnable on that CPU.
> > > > + */
> > > > + util_est = cpu_rq(cpu)->cfs.util_est_runnable;
> > > > + util = max(util, util_est);
> > > > +
> > > > + return util;
> >
> > I should instead clamp util before returning it! ;-)
> >
> > > May be a separate patch to remove the clamping part?
> >
> > No, I think we should keep cpu_util_wake clamped to not affect the existing
> > call sites. I just need to remove it where not needed (done) and add it where
> > needed (will do on the next iteration).
>
> cpu_util_wake() is called only from capacity_spare_wake(). There are no other
> callsites.
True...
> The capacity_spare_wake() is clamping the return value of
> cpu_util_wake() to CPU capacity.
... actually it's clamping negative numbers with:
max_t(long, capacity_of(cpu) - cpu_util_wake(cpu, p), 0);
thus, by having cpu_util_wake returning potentially a value which is
bigger then capacity_of or capacity_orig_of we should not have issues
from a capacity_spare_wake() usage standpoint.
> The clamping is not needed, I think.
However, we can still argue that the cpu_util_wake() should never
return something bigger then the maximum possible capacity of a CPU.
At least that's the feature so fare.
Thus, even just for the sake of consistency, with previous returns
paths (e.g. when we bail out returning cpu_util), I would say that
it's worth to maintain this semantics.
With a clamping, all these functions:
- cpu_util
- cpu_util_est
- cpu_util_wake
will always return a signal which is never bigger then the maximum
possible CPU capacity.
--
#include <best/regards.h>
Patrick Bellasi
next prev parent reply other threads:[~2018-01-31 15:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 18:08 [PATCH v3 0/3] Utilization estimation (util_est) for FAIR tasks Patrick Bellasi
2018-01-23 18:08 ` [PATCH v3 1/3] sched/fair: add util_est on top of PELT Patrick Bellasi
2018-01-24 16:40 ` Joel Fernandes
2018-01-24 19:16 ` Patrick Bellasi
2018-01-24 22:06 ` Joel Fernandes
2018-01-29 16:36 ` Peter Zijlstra
2018-01-30 12:46 ` Patrick Bellasi
2018-01-30 13:04 ` Peter Zijlstra
2018-01-30 14:01 ` Peter Zijlstra
2018-02-05 17:49 ` Patrick Bellasi
2018-01-23 18:08 ` [PATCH v3 2/3] sched/fair: use util_est in LB and WU paths Patrick Bellasi
2018-01-24 11:33 ` Pavan Kondeti
2018-01-24 19:31 ` Patrick Bellasi
2018-01-25 14:33 ` Pavan Kondeti
2018-01-31 15:32 ` Patrick Bellasi [this message]
2018-01-23 18:08 ` [PATCH v3 3/3] sched/cpufreq_schedutil: use util_est for OPP selection Patrick Bellasi
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=20180131153223.GD5739@e110439-lin \
--to=patrick.bellasi@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=pkondeti@codeaurora.org \
--cc=rafael.j.wysocki@intel.com \
--cc=smuckle@google.com \
--cc=tkjos@android.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 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.