[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180316132506.GF4064@hirez.programming.kicks-ass.net>
Date: Fri, 16 Mar 2018 14:25:06 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Patrick Bellasi <patrick.bellasi@....com>
Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Paul Turner <pjt@...gle.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Morten Rasmussen <morten.rasmussen@....com>,
Juri Lelli <juri.lelli@...hat.com>,
Todd Kjos <tkjos@...roid.com>,
Joel Fernandes <joelaf@...gle.com>,
Steve Muckle <smuckle@...gle.com>
Subject: Re: [PATCH v6 0/4] Utilization estimation (util_est) for FAIR tasks
On Fri, Mar 09, 2018 at 09:52:41AM +0000, Patrick Bellasi wrote:
> Hi, here is an update of [1], based on today's tip/sched/core [2], which mainly
> adds some code cleanups suggested by Peter as well as fixes compilation for
> !CONFIG_SMP systems.
>
> Most notably:
> a) The util_est's update flag has been renamed into UTIL_AVG_UNCHANGED, which
> seems to better match its usages.
> b) The cpu_util_est() function has been removed to reduce cluttering by folding
> its code directly into cpu_util(). This last function is thus now always
> returning the estimated utilization of a CPU, unless this sched feature is
> disabled.
> c) Not necessary READ_ONCE() have been removed from rq-lock protected code
> paths. For util_est variable, that we read/modify/write only from rq-lock
> protected, code we keep just the WRITE_ONCE() barriers, which are still
> required for synchronization with lockless readers.
> The READ_ONCE() have been instead maintained in all the getter functions,
> like for example task_util() and cpu_util(), which can potentially be used
> by lockless code. e.g. schedutil or load-balancer.
>
> Results on both x86_64 and ARM (Android) targets, which have been collected and
> reported in previous postings [1,3], show negligible overheads, especially
> compared to the corresponding power/performance benefits on mobile platforms,
> where this feature helps to reduce the performance gap between PELT and another
> other out-of-tree load tracking solution.
Thanks Patrick!
Powered by blists - more mailing lists