Re: [RFC patch 1/2] sched: dynamically adapt granularity withnr_running

From: Peter Zijlstra
Date: Mon Sep 13 2010 - 10:02:29 EST


On Mon, 2010-09-13 at 15:54 +0200, Peter Zijlstra wrote:
> On Mon, 2010-09-13 at 09:52 -0400, Steven Rostedt wrote:
> > On Mon, 2010-09-13 at 10:41 +0200, Peter Zijlstra wrote:
> >
> > > Yeah, without it you can starve the already running task on massive
> > > forks.
> > >
> > > Still, I'm not quite sure why people really care about fork() on time
> > > sensitive paths, its a very expensive thing to do, pre-fork() and wake
> > > when you need it, is what I would say.
> >
> > Fork is used all over the place in Linux. Every shell script uses it to
> > execute commands. Bad fork behavior shows up in just doing a build of
> > the kernel.
>
> Sure, but there's a difference between bad fork behaviour and the lowest
> possible latency. But maybe I'm too paranoid from doing -rt, but the
> first thing I'd do is get all resource allocations out from your fast
> path.

That is, with fork there's a trace-off between disrupting existing tasks
and their expectations, and running the new child.

There's also the issue that letting the parent run a little longer could
result in more runnable children, yielding greater parallelism.

If you push the new child all the way to the front, tasks that prefer
the parent to run a little more will suck, and vs.

IIRC kbuild likes the child to be late, it allows make to spawn more
kids and it'll got sleep on completion once it done anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/