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:	Sun, 12 Sep 2010 09:21:38 +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 Sun, 2010-09-12 at 08:14 +0200, Ingo Molnar wrote:
> * Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
> > (on a uniprocessor 2.0 GHz Pentium M)
> > 
> > * Without the patch:
> > 
> >  - wakeup-latency with SIGEV_THREAD in parallel with youtube video and
> >    make -j10
> > 
> > maximum latency: 50107.8 µs
> > average latency: 6609.2 µs
> > missed timer events: 0
> 
> I tried your patches on a similar UP system, using wakeup-latency.c. I 
> also measured the vanilla upstream kernel (cced86a) with the default 
> granularity settings, and also vanilla with a sched_min_granularity/3 
> tune (patch attached below for that).
> 
> I got the following results (make -j10 kbuild load, average of 3 runs):
> 
>  vanilla: 
> 
>   maximum latency: 38278.9 µs
>   average latency:  7730.1 µs
> 
>  mathieu-dyn:
> 
>   maximum latency: 28698.8 µs
>   average latency:  7757.1 µs
> 
>  peterz-min_gran/3:
> 
>   maximum latency: 22702.1 µs
>   average latency:  6684.8 µs

One thing that springs to mind with make is that it does vfork, so kinda
sorta continues running in drag, so shouldn't get credit for sleeping,
as that introduces bogus spread.  Post vfork parent notification time
adjustment may suffice, think I'll try that.

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