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

[Peter Zijlstra <peterz@infradead.org>]

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.