* Nick Piggin <[EMAIL PROTECTED]> 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); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/