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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 14 Sep 2010 13:46:21 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Ingo Molnar <mingo@...e.hu>
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)

* Ingo Molnar (mingo@...e.hu) wrote:
> 
> * 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?

I'm working on a new version at the moment. The previous one had a few bugs in
it when it comes to weight updates, and I fear some of the latency improvements
I've seen were caused by the whole build process ending up being niced all the
time. I'm currently working on a "simplified but not optimal" version, with
added sched_debug output, to make sure I get it right.

I'll keep you posted.

Thanks!

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/