Messages in this thread | | | Date | Tue, 14 Sep 2010 13:46:21 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH] sched: START_NICE feature (temporarily niced forks) |
| |
* Ingo Molnar (mingo@elte.hu) wrote: > > * 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?
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |