linux-kernel - Re: [RFC PATCH] sched: START_NICE feature (temporarily niced forks)

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: <20100914174345.GB3822@elte.hu>
Date:	Tue, 14 Sep 2010 19:43:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>,
	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] sched: START_NICE feature (temporarily niced forks)


* Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> This patch tweaks the nice value of both the parent and the child 
> after a fork to a higher nice value, but this is only applied to their 
> first slice after the fork. The goal of this scheme is that their 
> respective vruntime will increment faster in the first slice after the 
> fork, so a workload doing many forks (e.g. make -j10) will have a 
> limited impact on latency-sensitive workloads.
> 
> This is an alternative to START_DEBIT which does not have the downside 
> of moving newly forked threads to the end of the runqueue.
> 
> Latency benchmark:
> 
> * wakeup-latency.c (SIGEV_THREAD) with make -j10 on UP 2.0GHz
> 
> Kernel used: mainline 2.6.35.2 with smaller min_granularity and check_preempt
> vruntime vs runtime comparison patches applied.
> 
> - START_DEBIT (vanilla setting)
> 
> maximum latency: 26409.0 µs
> average latency: 6762.1 µs
> missed timer events: 0
> 
> - NO_START_DEBIT, NO_START_NICE
> 
> maximum latency: 10001.8 µs
> average latency: 1618.7 µs
> missed timer events: 0

Tempting ...

> 
> - START_NICE
> 
> maximum latency: 9873.9 µs
> average latency: 901.2 µs
> missed timer events: 0

Even more tempting! :)

> On the Xorg interactivity aspect, I notice a major improvement with 
> START_NICE compared to the two other settings. I just came up with a 
> very simple repeatable low-tech test that takes into account both 
> input and video update responsiveness:
> 
> Start make -j10 in a gnome-terminal In another gnome-terminal, start 
> pressing the space bar, holding it. Use the cursor speed (my cursor is 
> a full rectangle) as latency indicator. With low latency, its speed 
> should be constant, no stopping and no sudden acceleration.

You may want to run this by Mike - he's the expert on finding 
interactivity corner-case workloads with scheduler patches. Mike,
got time to try out Mathieu's patch?

	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/