lkml.org 
[lkml]   [2014]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2014-06-03 15:21    [W:0.214 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site