From: Ingo Molnar <mingo@elte.hu>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC PATCH] sched: START_NICE feature (temporarily niced forks)
Date: Tue, 14 Sep 2010 19:43:45 +0200 [thread overview]
Message-ID: <20100914174345.GB3822@elte.hu> (raw)
In-Reply-To: <20100914070718.GA25117@Krystal>
* 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
next prev parent reply other threads:[~2010-09-14 17:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-14 7:07 [RFC PATCH] sched: START_NICE feature (temporarily niced forks) Mathieu Desnoyers
2010-09-14 17:43 ` Ingo Molnar [this message]
2010-09-14 17:46 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100914174345.GB3822@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tony@atomide.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.