From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <npiggin@suse.de>
Cc: Davide Libenzi <davidel@xmailserver.org>,
Gene Heskett <gene.heskett@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Con Kolivas <kernel@kolivas.org>, Mike Galbraith <efault@gmx.de>,
Arjan van de Ven <arjan@infradead.org>,
Peter Williams <pwil3058@bigpond.net.au>,
Thomas Gleixner <tglx@linutronix.de>,
caglar@pardus.org.tr, Willy Tarreau <w@1wt.eu>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>
Subject: Re: [patch] CFS (Completely Fair Scheduler), v2
Date: Tue, 17 Apr 2007 10:26:31 +0200 [thread overview]
Message-ID: <20070417082628.GD5076@elte.hu> (raw)
In-Reply-To: <20070417081857.GD20026@wotan.suse.de>
* Nick Piggin <npiggin@suse.de> wrote:
> Actually I think this is something that makes sense to add, even if
> just for debugging, but maybe also for production, depending on how
> much it impacts things. Child runs first is an heuristic optimisation
> that exploits a VM detail (however fundamental). But for things that
> don't exec right after forking (and maybe some things that do), it can
> be nicer to reduce context switches, improve cache patterns, and allow
> children to be load balanced away before touching memory, if
> child_runs_first is turned off.
yeah, the primary intent was debug. Nick, am i confused to conclude that
mainline in fact runs the _parent_ first, despite all the elaborate
runqueue juggling we do there? This piece of code in wake_up_new_task()
caught my eyes:
p->prio = current->prio;
p->normal_prio = current->normal_prio;
list_add_tail(&p->run_list, ¤t->run_list);
p->array = current->array;
p->array->nr_active++;
inc_nr_running(p, rq);
shouldnt the list_add_tail() be list_add(), so that task pickup sees the
child first? Maybe we still do child-runs-first in practice, due to the
timeslice and sleep average fixups that happen if the parent preempts,
but the above piece of code seems a quite elaborate way of doing
activate_task(). To have the child _before_ the parent we'd need the
add-on patch below. But ... i could be wrong, this is just a quick
thought.
Ingo
---
kernel/sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -1685,7 +1685,7 @@ void fastcall wake_up_new_task(struct ta
else {
p->prio = current->prio;
p->normal_prio = current->normal_prio;
- list_add_tail(&p->run_list, ¤t->run_list);
+ list_add(&p->run_list, ¤t->run_list);
p->array = current->array;
p->array->nr_active++;
inc_nr_running(p, rq);
next prev parent reply other threads:[~2007-04-17 8:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-16 22:07 [patch] CFS (Completely Fair Scheduler), v2 Ingo Molnar
2007-04-16 22:12 ` S.Çağlar Onur
2007-04-17 8:59 ` Ingo Molnar
2007-04-17 14:45 ` S.Çağlar Onur
2007-04-17 15:48 ` Gabriel C
2007-04-17 16:01 ` Ingo Molnar
2007-04-17 4:06 ` Peter Williams
2007-04-17 6:49 ` Ingo Molnar
2007-04-17 4:53 ` Gene Heskett
2007-04-17 5:25 ` Willy Tarreau
2007-04-17 5:51 ` Gene Heskett
2007-04-17 7:18 ` Paolo Ornati
2007-04-17 5:51 ` Mike Galbraith
2007-04-17 6:27 ` Ingo Molnar
2007-04-18 0:06 ` Peter Williams
2007-04-17 6:18 ` Ingo Molnar
2007-04-17 7:01 ` Ingo Molnar
2007-04-17 7:31 ` Davide Libenzi
2007-04-17 7:39 ` Ingo Molnar
2007-04-17 17:18 ` Gene Heskett
2007-04-17 17:15 ` Gene Heskett
2007-04-17 17:22 ` Gene Heskett
2007-04-17 8:03 ` Davide Libenzi
2007-04-17 8:18 ` Nick Piggin
2007-04-17 8:26 ` Ingo Molnar [this message]
2007-04-17 8:41 ` Nick Piggin
2007-04-17 8:57 ` Ingo Molnar
2007-04-17 8:20 ` Ingo Molnar
2007-04-17 16:12 ` Gene Heskett
2007-04-17 6:46 ` Peter Williams
2007-04-17 7:51 ` William Lee Irwin III
2007-04-17 8:16 ` Ingo Molnar
2007-04-17 8:52 ` Ingo Molnar
2007-04-17 14:05 ` Peter Williams
2007-04-17 8:30 ` Peter Williams
2007-04-18 19:15 ` Peter Williams
2007-04-17 9:53 ` 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=20070417082628.GD5076@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=caglar@pardus.org.tr \
--cc=davidel@xmailserver.org \
--cc=dmitry.adamushko@gmail.com \
--cc=efault@gmx.de \
--cc=gene.heskett@gmail.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=pwil3058@bigpond.net.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/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.