linux-kernel - Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Sep 2010 13:22:04 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Mike Galbraith <efault@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [RFC patch 1/2] sched: dynamically adapt granularity with
 nr_running

* Peter Zijlstra <peterz@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/