From: dimm <dmitry.adamushko@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Roman Zippel <zippel@linux-m68k.org>,
Mike Galbraith <efault@gmx.de>,
dmitry.adamushko@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [announce] CFS-devel, performance improvements
Date: Fri, 14 Sep 2007 01:25:40 +0200 [thread overview]
Message-ID: <1189725940.4485.53.camel@earth> (raw)
and here's something a bit more intrusive.
The initial idea was to completely get rid of 'se->fair_key'. It's always equal to 'se->vruntime' for
all runnable tasks but the 'current'. The exact key within the tree for the 'current' has to be known in
order for __enqueue_entity() to work properly (if we just use 'vruntime', we may go a wrong way down the tree
while looking for the correct position for a new element).
Sure, it's possible to cache the current's key in the 'cfs_rq' and add a few additional checks, but that's
not very nice... so what if we don't keep the 'current' within the tree? :-)
The illustration is below. Some bits can be missed so far but a patched kernel boots/works
(haven't done real regression tests yet... can say that the mail client is still working
at this very moment :-).
There are 2 benefits:
(1) no more 'fair_key' ;
(2) entity_tick() is simpler/more effective : 'update_curr()' now vs.
'dequeue_entity() + enqueue_entity()' before.
anyway, consider it as mainly an illustration of idea so far.
---
diff -upr linux-2.6.23-rc6/include/linux/sched.h linux-2.6.23-rc6-my/include/linux/sched.h
--- linux-2.6.23-rc6/include/linux/sched.h 2007-09-13 21:38:49.000000000 +0200
+++ linux-2.6.23-rc6-my/include/linux/sched.h 2007-09-13 23:01:21.000000000 +0200
@@ -890,7 +890,6 @@ struct load_weight {
* 6 se->load.weight
*/
struct sched_entity {
- s64 fair_key;
struct load_weight load; /* for load-balancing */
struct rb_node run_node;
unsigned int on_rq;
diff -upr linux-2.6.23-rc6/kernel/sched.c linux-2.6.23-rc6-my/kernel/sched.c
--- linux-2.6.23-rc6/kernel/sched.c 2007-09-13 21:52:13.000000000 +0200
+++ linux-2.6.23-rc6-my/kernel/sched.c 2007-09-13 23:00:19.000000000 +0200
@@ -6534,7 +6534,6 @@ void normalize_rt_tasks(void)
read_lock_irq(&tasklist_lock);
do_each_thread(g, p) {
- p->se.fair_key = 0;
p->se.exec_start = 0;
#ifdef CONFIG_SCHEDSTATS
p->se.wait_start = 0;
diff -upr linux-2.6.23-rc6/kernel/sched_debug.c linux-2.6.23-rc6-my/kernel/sched_debug.c
--- linux-2.6.23-rc6/kernel/sched_debug.c 2007-09-13 21:52:13.000000000 +0200
+++ linux-2.6.23-rc6-my/kernel/sched_debug.c 2007-09-13 23:00:50.000000000 +0200
@@ -38,7 +38,7 @@ print_task(struct seq_file *m, struct rq
SEQ_printf(m, "%15s %5d %15Ld %13Ld %5d ",
p->comm, p->pid,
- (long long)p->se.fair_key,
+ (long long)p->se.vruntime,
(long long)(p->nvcsw + p->nivcsw),
p->prio);
#ifdef CONFIG_SCHEDSTATS
diff -upr linux-2.6.23-rc6/kernel/sched_fair.c linux-2.6.23-rc6-my/kernel/sched_fair.c
--- linux-2.6.23-rc6/kernel/sched_fair.c 2007-09-13 21:52:13.000000000 +0200
+++ linux-2.6.23-rc6-my/kernel/sched_fair.c 2007-09-13 23:48:02.000000000 +0200
@@ -125,7 +125,7 @@ set_leftmost(struct cfs_rq *cfs_rq, stru
s64 entity_key(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
- return se->fair_key - cfs_rq->min_vruntime;
+ return se->vruntime - cfs_rq->min_vruntime;
}
/*
@@ -167,9 +167,6 @@ __enqueue_entity(struct cfs_rq *cfs_rq,
rb_link_node(&se->run_node, parent, link);
rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
- update_load_add(&cfs_rq->load, se->load.weight);
- cfs_rq->nr_running++;
- se->on_rq = 1;
}
static void
@@ -179,9 +176,6 @@ __dequeue_entity(struct cfs_rq *cfs_rq,
set_leftmost(cfs_rq, rb_next(&se->run_node));
rb_erase(&se->run_node, &cfs_rq->tasks_timeline);
- update_load_sub(&cfs_rq->load, se->load.weight);
- cfs_rq->nr_running--;
- se->on_rq = 0;
}
static inline struct rb_node *first_fair(struct cfs_rq *cfs_rq)
@@ -320,10 +314,6 @@ static void update_stats_enqueue(struct
*/
if (se != cfs_rq->curr)
update_stats_wait_start(cfs_rq, se);
- /*
- * Update the key:
- */
- se->fair_key = se->vruntime;
}
static void
@@ -371,6 +361,22 @@ update_stats_curr_end(struct cfs_rq *cfs
* Scheduling class queueing methods:
*/
+static void
+account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se)
+{
+ update_load_add(&cfs_rq->load, se->load.weight);
+ cfs_rq->nr_running++;
+ se->on_rq = 1;
+}
+
+static void
+account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
+{
+ update_load_sub(&cfs_rq->load, se->load.weight);
+ cfs_rq->nr_running--;
+ se->on_rq = 0;
+}
+
static void enqueue_sleeper(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
#ifdef CONFIG_SCHEDSTATS
@@ -446,7 +452,9 @@ enqueue_entity(struct cfs_rq *cfs_rq, st
}
update_stats_enqueue(cfs_rq, se);
- __enqueue_entity(cfs_rq, se);
+ if (se != cfs_rq->curr)
+ __enqueue_entity(cfs_rq, se);
+ account_entity_enqueue(cfs_rq, se);
}
static void
@@ -465,7 +473,9 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
}
}
#endif
- __dequeue_entity(cfs_rq, se);
+ if (se != cfs_rq->curr)
+ __dequeue_entity(cfs_rq, se);
+ account_entity_dequeue(cfs_rq, se);
}
/*
@@ -511,6 +521,9 @@ static struct sched_entity *pick_next_en
{
struct sched_entity *se = __pick_next_entity(cfs_rq);
+ if (se)
+ __dequeue_entity(cfs_rq, se);
+
set_next_entity(cfs_rq, se);
return se;
@@ -522,8 +535,11 @@ static void put_prev_entity(struct cfs_r
* If still on the runqueue then deactivate_task()
* was not called and update_curr() has to be done:
*/
- if (prev->on_rq)
+ if (prev->on_rq) {
update_curr(cfs_rq);
+ /* Put the current back into the tree. */
+ __enqueue_entity(cfs_rq, prev);
+ }
update_stats_curr_end(cfs_rq, prev);
@@ -535,11 +551,9 @@ static void put_prev_entity(struct cfs_r
static void entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
{
/*
- * Dequeue and enqueue the task to update its
- * position within the tree:
+ * Update run-time statistics of the 'current'.
*/
- dequeue_entity(cfs_rq, curr, 0);
- enqueue_entity(cfs_rq, curr, 0);
+ update_curr(cfs_rq);
if (cfs_rq->nr_running > 1)
check_preempt_tick(cfs_rq, curr);
@@ -890,6 +904,7 @@ static void task_new_fair(struct rq *rq,
update_stats_enqueue(cfs_rq, se);
__enqueue_entity(cfs_rq, se);
+ account_entity_enqueue(cfs_rq, se);
resched_task(rq->curr);
}
---
next reply other threads:[~2007-09-13 23:25 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-13 23:25 dimm [this message]
2007-09-14 8:17 ` [announce] CFS-devel, performance improvements Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2007-09-13 22:51 dimm
2007-09-14 8:13 ` Ingo Molnar
2007-09-14 8:13 ` Ingo Molnar
2007-09-11 20:04 Ingo Molnar
2007-09-12 0:42 ` Roman Zippel
2007-09-13 7:52 ` Ingo Molnar
2007-09-13 12:35 ` Roman Zippel
2007-09-13 14:28 ` Ingo Molnar
2007-09-13 16:50 ` Roman Zippel
2007-09-13 17:06 ` Peter Zijlstra
2007-09-13 17:09 ` Peter Zijlstra
2007-09-14 12:04 ` Roman Zippel
2007-09-14 12:17 ` Peter Zijlstra
2007-09-13 18:28 ` Kyle Moffett
2007-09-13 19:08 ` Peter Zijlstra
2007-09-14 15:26 ` Arjan van de Ven
2007-09-14 14:50 ` Roman Zippel
2007-09-14 15:56 ` Arjan van de Ven
2007-09-14 15:13 ` Roman Zippel
2007-09-13 19:01 ` Sam Ravnborg
2007-09-14 12:26 ` Roman Zippel
2007-09-12 1:16 ` Rob Hussey
2007-09-13 8:42 ` Rob Hussey
2007-09-13 9:06 ` Ingo Molnar
2007-09-13 9:24 ` Rob Hussey
2007-09-13 9:31 ` Ingo Molnar
2007-09-13 9:36 ` Rob Hussey
2007-09-13 9:43 ` Rob Hussey
2007-09-13 10:17 ` Rob Hussey
2007-09-13 11:48 ` Ingo Molnar
2007-09-14 1:47 ` Rob Hussey
2007-09-14 2:26 ` Rob Hussey
2007-09-14 6:59 ` Kyle Moffett
2007-09-12 6:20 ` Mike Galbraith
2007-09-12 22:17 ` Roman Zippel
2007-09-13 7:17 ` debian developer
2007-09-13 7:34 ` debian developer
2007-09-13 9:19 ` Ingo Molnar
2007-09-13 11:35 ` Peter Zijlstra
2007-09-13 12:14 ` Roman Zippel
2007-09-13 12:44 ` Peter Zijlstra
2007-09-14 11:16 ` Peter Zijlstra
2007-09-13 12:47 ` Ingo Molnar
2007-09-14 11:46 ` Roman Zippel
2007-09-13 23:08 ` Willy Tarreau
2007-09-14 13:10 ` Roman Zippel
2007-09-14 17:54 ` Willy Tarreau
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=1189725940.4485.53.camel@earth \
--to=dmitry.adamushko@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=zippel@linux-m68k.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.