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]

Message-Id: <1284371457.14888.9.camel@marge.simson.net>
Date:	Mon, 13 Sep 2010 11:50:57 +0200
From:	Mike Galbraith <efault@....de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.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 11:37 +0200, Peter Zijlstra wrote:
> On Mon, 2010-09-13 at 11:16 +0200, Mike Galbraith wrote:
> > On Mon, 2010-09-13 at 10:35 +0200, Peter Zijlstra wrote:
> > > On Mon, 2010-09-13 at 09:08 +0200, Mike Galbraith wrote:
> > > > We need a better fork fairness gizmo.
> > > 
> > > Proper zero-lag insertion would do. Much sadness in that tracking that
> > > costs a u64 mult per enqueu/dequeue and using it adds a s64 div.
> > 
> > (math _sucks_:)
> > 
> > > But if you want, have a play with:
> > 
> > maximum latency: 48475.3 µs
> > average latency: 6881.4 µs
> > missed timer events: 0
> > 
> > Darn.
> > 
> > make -j3 is gaining a tad over a hog as well, roughly the same as
> > turning START_DEBIT off.
> 
> 
> Hrmm,. could it be fair_sleeper muck placing too many tasks too far left
> on wakeup starving others?

Yeah, pretty much has to be fair_sleepers holding others off for too
long.  (A shiny new preemption model is about the only thing that can
make that go away)  Perhaps lag should be negated if you've received a
reasonable chunk or something.. but what we really want is a service
deadline.

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