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 09:08:36 +0200
From:	Mike Galbraith <efault@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.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

On Mon, 2010-09-13 at 08:41 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@....de> wrote:
> 
> > On Sun, 2010-09-12 at 14:16 -0400, Mathieu Desnoyers wrote:
> 
> > > Or am I missing your point ?
> > 
> > Yes and no.  I'm pondering the parent, but by the same token, the 
> > vfork child shouldn't be penalized either.
> > 
> > Does your latency go down drastically if you turn START_DEBIT off? 
> > Seems like it should.  Perhaps START_DEBIT should not start a task 
> > further right than rightmost.  I've done that before.
> > 
> > maximum latency: 19221.5 µs
> > average latency: 5159.0 µs
> > missed timer events: 0
> > 
> > maximum latency: 43901.0 µs
> > average latency: 8430.1 µs
> > missed timer events: 0
> > 
> > Turning it off here cut latency roughly in half (i've piddled vfork 
> > though, but not completely).  Limiting child placement to no further 
> > right than rightmost should help quite a bit.
> 
> Very interesting observation. Mathieu, mind testing Mike's suggestion 
> with wakeup-latency.c?

I'm sure it will.  I think the problem is that light thread forks, the
child takes vruntime hit, so the parent's lag isn't _useful_.  It may
preempt, but the work it's trying to get done is delayed massively
unfairly.

btw, setting parent's lag to that of the child on parent wakeup for the
vfork case seems to work fine, kbuild no longer gets the advantage it
would vs static load if START_DEBIT were disabled.  That leaves what to
do with plain old fork/clone though.  Leaving START_DEBIT in place for
fork/clone vs a fair vfork load blows chunks, as does running a forky
load vs some static load without START_DEBIT.

Sticky wicket.  We need a better fork fairness gizmo.

	-Mike

--
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/