Thread (30 messages) 30 messages, 3 authors, 2014-06-11

Re: [RFC PATCH 03/16 v3] How CC accrues with run queue change and time

From: Peter Zijlstra <peterz@infradead.org>
Date: 2014-06-03 12:12:55
Also in: lkml

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 <redacted>
---
 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.

Attachments

  • (unnamed) [application/pgp-signature] 836 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help