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

[Mathieu Desnoyers]

* Ingo Molnar (mingo@xxxxxxx) wrote:
> 
> * Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/