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 16:02:11 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.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>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [RFC patch 1/2] sched: dynamically adapt granularity with
 nr_running

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/