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

From: Ingo Molnar
Date: Mon Sep 13 2010 - 07:22:23 EST



* Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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
--
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/