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

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, 2010-09-13 at 06:35 +0200, Mike Galbraith wrote:
> > On Sun, 2010-09-12 at 11:06 +0200, Peter Zijlstra wrote:
> > > On Sat, 2010-09-11 at 13:48 -0700, Linus Torvalds wrote:
> > 
> > > > And I don't like how you dismissed the measured latency improvement.
> > > > And yes, I do think latency matters. A _lot_.
> > > 
> > > OK, we'll make it better and sacrifice some throughput, can do, no
> > > problem.
> > 
> > I'm not seeing high wakeup latencies, even under hefty load.  
> > Mathieu's testcase is bad, but apparently solely due to START_DEBIT 
> > placement. That's kind of a sticky wicket.  I've shot it in the 
> > heart before, but regretted doing so when I looked at kbuild vs 
> > static load fairness.
> 
> 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.

Right. So what happens in practice is that some desktop apps tend to be 
fork happy and it doesnt show up on low load so why not? The kernel 
forks plenty fast:

  aldebaran:~/l> ./lat_proc fork
  Process fork+exit: 165.9254 microseconds

So even a full-blown fork() is a drop in the ocean of desktop bloat. 
Firefox takes 100-300 msecs CPU time to process a single tab click ... 
it's insane.

fork() is also a very convenient and robust prgramming facility: COW 
gives us immutable data inheritance - match that thread programmers ...

Plus it's not just fork()s but also pthread_create() obviously - which 
is even faster.

So yes, it happens all the time, and if we create some bad latency of 
10-20 msecs under load (or more), it gets noticed - especially if it's 
some cumulative fork() chain of processing.

And no, we cannot rely on pre-forking - and we dont even _want_ to, 
fork() and pthread_create() is a perfectly valid facility. In the 
scheduler we have to handle fork()/pthread_create() smoothly.

Thanks,

	Ingo