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

[Ingo Molnar <mingo@elte.hu>]

* Mathieu Desnoyers <mathieu.desnoyers@efficios.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