From: Ingo Molnar <mingo@elte.hu>
To: Al Boldi <a1426z@gawab.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Mike Galbraith <efault@gmx.de>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: CFS review
Date: Mon, 27 Aug 2007 12:53:17 +0200 [thread overview]
Message-ID: <20070827105317.GA15003@elte.hu> (raw)
In-Reply-To: <200708270706.41565.a1426z@gawab.com>
* Al Boldi <a1426z@gawab.com> wrote:
> > could you send the exact patch that shows what you did?
>
> On 2.6.22.5-v20.3 (not v20.4):
>
> 340- curr->delta_exec += delta_exec;
> 341-
> 342- if (unlikely(curr->delta_exec > sysctl_sched_stat_granularity)) {
> 343:// __update_curr(cfs_rq, curr);
> 344- curr->delta_exec = 0;
> 345- }
> 346- curr->exec_start = rq_of(cfs_rq)->clock;
ouch - this produces a really broken scheduler - with this we dont do
any run-time accounting (!).
Could you try the patch below instead, does this make 3x glxgears smooth
again? (if yes, could you send me your Signed-off-by line as well.)
Ingo
------------------------>
Subject: sched: make the scheduler converge to the ideal latency
From: Ingo Molnar <mingo@elte.hu>
de-HZ-ification of the granularity defaults unearthed a pre-existing
property of CFS: while it correctly converges to the granularity goal,
it does not prevent run-time fluctuations in the range of [-gran ...
+gran].
With the increase of the granularity due to the removal of HZ
dependencies, this becomes visible in chew-max output (with 5 tasks
running):
out: 28 . 27. 32 | flu: 0 . 0 | ran: 9 . 13 | per: 37 . 40
out: 27 . 27. 32 | flu: 0 . 0 | ran: 17 . 13 | per: 44 . 40
out: 27 . 27. 32 | flu: 0 . 0 | ran: 9 . 13 | per: 36 . 40
out: 29 . 27. 32 | flu: 2 . 0 | ran: 17 . 13 | per: 46 . 40
out: 28 . 27. 32 | flu: 0 . 0 | ran: 9 . 13 | per: 37 . 40
out: 29 . 27. 32 | flu: 0 . 0 | ran: 18 . 13 | per: 47 . 40
out: 28 . 27. 32 | flu: 0 . 0 | ran: 9 . 13 | per: 37 . 40
average slice is the ideal 13 msecs and the period is picture-perfect 40
msecs. But the 'ran' field fluctuates around 13.33 msecs and there's no
mechanism in CFS to keep that from happening: it's a perfectly valid
solution that CFS finds.
the solution is to add a granularity/preemption rule that knows about
the "target latency", which makes tasks that run longer than the ideal
latency run a bit less. The simplest approach is to simply decrease the
preemption granularity when a task overruns its ideal latency. For this
we have to track how much the task executed since its last preemption.
( this adds a new field to task_struct, but we can eliminate that
overhead in 2.6.24 by putting all the scheduler timestamps into an
anonymous union. )
with this change in place, chew-max output is fluctuation-less all
around:
out: 28 . 27. 39 | flu: 0 . 2 | ran: 13 . 13 | per: 41 . 40
out: 28 . 27. 39 | flu: 0 . 2 | ran: 13 . 13 | per: 41 . 40
out: 28 . 27. 39 | flu: 0 . 2 | ran: 13 . 13 | per: 41 . 40
out: 28 . 27. 39 | flu: 0 . 2 | ran: 13 . 13 | per: 41 . 40
out: 28 . 27. 39 | flu: 0 . 1 | ran: 13 . 13 | per: 41 . 40
out: 28 . 27. 39 | flu: 0 . 1 | ran: 13 . 13 | per: 41 . 40
this patch has no impact on any fastpath or on any globally observable
scheduling property. (unless you have sharp enough eyes to see
millisecond-level ruckles in glxgears smoothness :-)
Also, with this mechanism in place the formula for adaptive granularity
can be simplified down to the obvious "granularity = latency/nr_running"
calculation.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
include/linux/sched.h | 1 +
kernel/sched_fair.c | 43 ++++++++++++++-----------------------------
2 files changed, 15 insertions(+), 29 deletions(-)
Index: linux/include/linux/sched.h
===================================================================
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -904,6 +904,7 @@ struct sched_entity {
u64 exec_start;
u64 sum_exec_runtime;
+ u64 prev_sum_exec_runtime;
u64 wait_start_fair;
u64 sleep_start_fair;
Index: linux/kernel/sched_fair.c
===================================================================
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -225,30 +225,6 @@ static struct sched_entity *__pick_next_
* Calculate the preemption granularity needed to schedule every
* runnable task once per sysctl_sched_latency amount of time.
* (down to a sensible low limit on granularity)
- *
- * For example, if there are 2 tasks running and latency is 10 msecs,
- * we switch tasks every 5 msecs. If we have 3 tasks running, we have
- * to switch tasks every 3.33 msecs to get a 10 msecs observed latency
- * for each task. We do finer and finer scheduling up to until we
- * reach the minimum granularity value.
- *
- * To achieve this we use the following dynamic-granularity rule:
- *
- * gran = lat/nr - lat/nr/nr
- *
- * This comes out of the following equations:
- *
- * kA1 + gran = kB1
- * kB2 + gran = kA2
- * kA2 = kA1
- * kB2 = kB1 - d + d/nr
- * lat = d * nr
- *
- * Where 'k' is key, 'A' is task A (waiting), 'B' is task B (running),
- * '1' is start of time, '2' is end of time, 'd' is delay between
- * 1 and 2 (during which task B was running), 'nr' is number of tasks
- * running, 'lat' is the the period of each task. ('lat' is the
- * sched_latency that we aim for.)
*/
static long
sched_granularity(struct cfs_rq *cfs_rq)
@@ -257,7 +233,7 @@ sched_granularity(struct cfs_rq *cfs_rq)
unsigned int nr = cfs_rq->nr_running;
if (nr > 1) {
- gran = gran/nr - gran/nr/nr;
+ gran = gran/nr;
gran = max(gran, sysctl_sched_min_granularity);
}
@@ -668,7 +644,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
/*
* Preempt the current task with a newly woken task if needed:
*/
-static void
+static int
__check_preempt_curr_fair(struct cfs_rq *cfs_rq, struct sched_entity *se,
struct sched_entity *curr, unsigned long granularity)
{
@@ -679,8 +655,11 @@ __check_preempt_curr_fair(struct cfs_rq
* preempt the current task unless the best task has
* a larger than sched_granularity fairness advantage:
*/
- if (__delta > niced_granularity(curr, granularity))
+ if (__delta > niced_granularity(curr, granularity)) {
resched_task(rq_of(cfs_rq)->curr);
+ return 1;
+ }
+ return 0;
}
static inline void
@@ -725,6 +704,7 @@ static void put_prev_entity(struct cfs_r
static void entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
{
+ unsigned long gran, delta_exec;
struct sched_entity *next;
/*
@@ -741,8 +721,13 @@ static void entity_tick(struct cfs_rq *c
if (next == curr)
return;
- __check_preempt_curr_fair(cfs_rq, next, curr,
- sched_granularity(cfs_rq));
+ gran = sched_granularity(cfs_rq);
+ delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
+ if (delta_exec > gran)
+ gran = 0;
+
+ if (__check_preempt_curr_fair(cfs_rq, next, curr, gran))
+ curr->prev_sum_exec_runtime = curr->sum_exec_runtime;
}
/**************************************************
next prev parent reply other threads:[~2007-08-27 10:53 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-11 10:44 Al Boldi
2007-08-12 4:17 ` Ingo Molnar
2007-08-12 15:27 ` Al Boldi
2007-08-12 15:52 ` Ingo Molnar
2007-08-12 19:43 ` Al Boldi
2007-08-21 10:58 ` Ingo Molnar
2007-08-21 22:27 ` Al Boldi
2007-08-24 13:45 ` Ingo Molnar
2007-08-25 22:27 ` Al Boldi
2007-08-25 23:15 ` Ingo Molnar
2007-08-26 16:27 ` Al Boldi
2007-08-26 16:39 ` Ingo Molnar
2007-08-27 4:06 ` Al Boldi
2007-08-27 10:53 ` Ingo Molnar [this message]
2007-08-27 14:46 ` Al Boldi
2007-08-27 20:41 ` Ingo Molnar
2007-08-28 4:37 ` Al Boldi
2007-08-28 5:05 ` Linus Torvalds
2007-08-28 5:23 ` Al Boldi
2007-08-28 7:28 ` Mike Galbraith
2007-08-28 7:36 ` Ingo Molnar
2007-08-28 16:34 ` Linus Torvalds
2007-08-28 16:44 ` Arjan van de Ven
2007-08-28 16:45 ` Ingo Molnar
2007-08-29 4:19 ` Al Boldi
2007-08-29 4:53 ` Ingo Molnar
2007-08-29 5:58 ` Al Boldi
2007-08-29 6:43 ` Ingo Molnar
2007-08-28 20:46 ` Valdis.Kletnieks
2007-08-28 7:43 ` Xavier Bestel
2007-08-28 8:02 ` Ingo Molnar
2007-08-28 19:19 ` Willy Tarreau
2007-08-28 19:55 ` Ingo Molnar
2007-08-29 4:18 ` Ingo Molnar
2007-08-29 4:29 ` Keith Packard
2007-08-29 4:46 ` Ingo Molnar
2007-08-29 7:57 ` Keith Packard
2007-08-29 8:04 ` Ingo Molnar
2007-08-29 8:53 ` Al Boldi
2007-08-29 15:57 ` Keith Packard
2007-08-29 19:56 ` Rene Herman
2007-08-30 7:05 ` Rene Herman
2007-08-30 7:20 ` Ingo Molnar
2007-08-31 6:46 ` Tilman Sauerbeck
2007-08-31 10:44 ` DRM and/or X trouble (was Re: CFS review) Rene Herman
2007-08-31 14:55 ` DRM and/or X trouble Satyam Sharma
2007-08-30 16:06 ` CFS review Chuck Ebbert
2007-08-30 16:48 ` Rene Herman
2007-08-29 4:40 ` Mike Galbraith
2007-08-29 3:42 ` Bill Davidsen
2007-08-29 3:37 ` Bill Davidsen
2007-08-29 3:45 ` Ingo Molnar
2007-08-29 13:11 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2007-07-10 8:31 -mm merge plans for 2.6.23 Andrew Morton
2007-07-11 12:43 ` x86 status was " Andi Kleen
2007-07-11 17:42 ` Ingo Molnar
2007-07-11 21:16 ` Andi Kleen
2007-07-11 21:46 ` Andrea Arcangeli
2007-07-11 22:09 ` Linus Torvalds
2007-07-13 2:23 ` Roman Zippel
2007-07-13 4:47 ` Mike Galbraith
2007-07-13 17:23 ` Roman Zippel
2007-07-14 5:04 ` Mike Galbraith
2007-08-01 3:41 ` CFS review Roman Zippel
2007-08-01 7:12 ` Ingo Molnar
2007-08-01 7:26 ` Mike Galbraith
2007-08-01 7:30 ` Ingo Molnar
2007-08-01 7:36 ` Mike Galbraith
2007-08-01 8:49 ` Mike Galbraith
2007-08-01 13:19 ` Roman Zippel
2007-08-01 15:07 ` Ingo Molnar
2007-08-01 17:10 ` Andi Kleen
2007-08-01 16:27 ` Linus Torvalds
2007-08-01 17:48 ` Andi Kleen
2007-08-01 17:50 ` Ingo Molnar
2007-08-01 18:01 ` Roman Zippel
2007-08-01 19:05 ` Ingo Molnar
2007-08-09 23:14 ` Roman Zippel
2007-08-10 5:49 ` Ingo Molnar
2007-08-10 13:52 ` Roman Zippel
2007-08-10 14:18 ` Ingo Molnar
2007-08-10 16:47 ` Mike Galbraith
2007-08-10 17:19 ` Roman Zippel
2007-08-10 16:54 ` Michael Chang
2007-08-10 17:25 ` Roman Zippel
2007-08-10 19:44 ` Ingo Molnar
2007-08-10 19:47 ` Willy Tarreau
2007-08-10 21:15 ` Roman Zippel
2007-08-10 21:36 ` Ingo Molnar
2007-08-10 22:50 ` Roman Zippel
2007-08-11 5:28 ` Willy Tarreau
2007-08-12 5:17 ` Ingo Molnar
2007-08-11 0:30 ` Ingo Molnar
2007-08-20 22:19 ` Roman Zippel
2007-08-21 7:33 ` Mike Galbraith
2007-08-21 8:35 ` Ingo Molnar
2007-08-21 11:54 ` Roman Zippel
2007-08-11 5:15 ` Willy Tarreau
2007-08-10 7:23 ` Mike Galbraith
2007-08-01 11:22 ` Ingo Molnar
2007-08-01 12:21 ` Roman Zippel
2007-08-01 12:23 ` Ingo Molnar
2007-08-01 13:59 ` Ingo Molnar
2007-08-01 14:04 ` Arjan van de Ven
2007-08-01 15:44 ` Roman Zippel
2007-08-01 17:41 ` Ingo Molnar
2007-08-01 18:14 ` Roman Zippel
2007-08-03 3:04 ` Matt Mackall
2007-08-03 3:57 ` Arjan van de Ven
2007-08-03 4:18 ` Willy Tarreau
2007-08-03 4:31 ` Arjan van de Ven
2007-08-03 4:53 ` Willy Tarreau
2007-08-03 4:38 ` Matt Mackall
2007-08-03 8:44 ` Ingo Molnar
2007-08-03 9:29 ` Andi Kleen
2007-08-01 11:37 ` Ingo Molnar
2007-08-01 12:27 ` Roman Zippel
2007-08-01 13:20 ` Andi Kleen
2007-08-01 13:33 ` Roman Zippel
2007-08-01 14:36 ` Ingo Molnar
2007-08-01 16:11 ` Andi Kleen
2007-08-02 2:17 ` Linus Torvalds
2007-08-02 4:57 ` Willy Tarreau
2007-08-02 10:43 ` Andi Kleen
2007-08-02 10:07 ` Willy Tarreau
2007-08-02 16:09 ` Ingo Molnar
2007-08-02 22:38 ` Roman Zippel
2007-08-02 19:16 ` Daniel Phillips
2007-08-02 23:23 ` Roman Zippel
2007-08-01 14:40 ` Ingo Molnar
2007-08-01 14:49 ` Peter Zijlstra
2007-08-02 17:36 ` Roman Zippel
2007-08-02 15:46 ` Ingo Molnar
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=20070827105317.GA15003@elte.hu \
--to=mingo@elte.hu \
--cc=a1426z@gawab.com \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome