Messages in this thread | | | Date | Tue, 3 Jun 2014 14:12:42 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 03/16 v3] How CC accrues with run queue change and time |
| |
On Fri, May 30, 2014 at 02:35:59PM +0800, Yuyang Du wrote: > It is natural to use task concurrency (running tasks in the rq) as load > indicator. We calculate CC for task concurrency by two steps: > > 1) Divide continuous time into periods of time, and average task concurrency > in period, for tolerating the transient bursts: > > a = sum(concurrency * time) / period > > 2) Exponentially decay past periods, and synthesize them all, for hysteresis > to load drops or resilience to load rises (let f be decaying factor, and a_x > the xth period average since period 0): > > s = a_n + f^1 * a_n-1 + f^2 * a_n-2 +, ..., + f^(n-1) * a_1 + f^n * a_0 > > To sum up, CPU CC is 1) decayed average run queue length, or 2) run-queue-lengh- > weighted CPU utilization.
why!? what benefit does it have over utilization.
Also, not a mention of dvfs or how that would impact things.
> Signed-off-by: Yuyang Du <yuyang.du@intel.com> > --- > kernel/sched/fair.c | 255 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 255 insertions(+)
And not a single word on why you cannot use the existing per-task accounting infrastructure and not a single attempt to merge the two.
[unhandled content-type:application/pgp-signature] | |