From: Mike Galbraith <efault@gmx.de>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC PATCH 00/11] sched: CFS low-latency features
Date: Sat, 28 Aug 2010 09:33:59 +0200 [thread overview]
Message-ID: <1282980839.17756.81.camel@marge.simson.net> (raw)
In-Reply-To: <20100827183830.GD22679@Krystal>
On Fri, 2010-08-27 at 14:38 -0400, Mathieu Desnoyers wrote:
> * Mathieu Desnoyers (mathieu.desnoyers@efficios.com) wrote:
> > * Mike Galbraith (efault@gmx.de) wrote:
> > > On Fri, 2010-08-27 at 09:42 +0200, Peter Zijlstra wrote:
> > > > On Thu, 2010-08-26 at 19:49 -0400, Mathieu Desnoyers wrote:
> > > > > AFAIK, I don't think we would end up starving the system in any possible way.
> > > >
> > > > Correct, it does maintain fairness.
> > > >
> > > > > So far I cannot see a situation where selecting the next buddy would _not_ make
> > > > > sense in any kind of input-driven wakeups (interactive, timer, disk, network,
> > > > > etc). But maybe it's just a lack of imagination on my part.
> > > >
> > > > The risk is that you end up with always using next-buddy, and we tried
> > > > that a while back and that didn't work well for some, Mike might
> > > > remember.
> > >
> > > I turned it off because it was ripping spread apart badly, and last
> > > buddy did a better job of improving scalability without it.
> >
> > Maybe with the dyn min_vruntime feature proposed in this patchset we should
> > reconsider this. Spread being ripped apart is exactly what it addresses.
Dunno. Messing with spread is a very sharp double edged sword.
I took the patch set out for a spin, and saw some negative effects in
that regard. I did see some positive effects as well though, x264 for
example really wants round robin, so profits. Things where preemption
translates to throughput don't care for the idea much. vmark rather
surprised me, it hated this feature for some reason, I expected the
opposite.
It's an interesting knob, but I wouldn't turn it on by default on
anything but maybe a UP desktop box.
(i kinda like cgroups classified by pgid for desktop interactivity under
load, works pretty darn well)
> I'm curious: which workload was showing this kind of problem exactly ?
Hm, I don't recall exact details. I was looking at a lot of different
load mixes at the time, mostly interactive and batch, trying to shrink
the too darn high latencies seen with modest load mixes.
I never tried to figure out why next buddy had worse effect on spread
than last buddy (not obvious to me), just noted the fact that it did. I
recall that it had a large negative effect on x264 throughput as well.
-Mike
some numbers:
35.3x = DYN_MIN_VRUNTIME
netperf TCP_RR
35.3 97624.82 96982.62 97387.50 avg 97331.646 RR/sec 1.000
35.3x 95044.98 95365.52 94581.92 avg 94997.473 RR/sec .976
tbench 8
35.3 1200.36 1200.56 1199.29 avg 1200.070 MB/sec 1.000
35.3x 1106.92 1110.50 1106.58 avg 1108.000 MB/sec .923
x264 8
35.3 407.12 408.80 414.60 avg 410.173 fps 1.000
35.3x 428.07 436.43 438.16 avg 434.220 fps 1.058
vmark
35.3 149678 149269 150584 avg 149843.666 m/sec 1.000
35.3x 120872 120932 121247 avg 121017.000 m/sec .807
mysql+oltp
1 2 4 8 16 32 64 128 256
35.3 10956.33 20747.86 37139.27 36898.70 36575.90 36104.63 34390.26 31574.46 29148.01
10938.44 20835.17 37058.51 37051.71 36630.06 35930.90 34464.88 32024.50 28989.14
10935.72 20792.54 37238.17 36989.97 36568.37 35961.00 34342.54 31532.39 29235.20
avg 10943.49 20791.85 37145.31 36980.12 36591.44 35998.84 34399.22 31710.45 29124.11
35.3x 10944.22 20851.09 35609.32 35744.05 35137.49 33362.16 30796.03 28286.87 25105.84
10958.68 20811.93 35604.57 35610.71 35147.65 33371.81 30877.52 28325.79 25113.85
10962.72 20745.81 35728.36 35638.23 35124.56 33336.20 30794.99 28225.99 25202.88
avg 10955.20 20802.94 35647.41 35664.33 35136.56 33356.72 30822.84 28279.55 25140.85
vs 35.3 1.001 1.000 .959 .964 .960 .926 .896 .891 .863
next prev parent reply other threads:[~2010-08-28 7:33 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-26 18:09 Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 01/11] sched: fix string comparison in features Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 02/11] sched: debug spread check account for nr_running Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 03/11] sched: FAIR_SLEEPERS feature Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 04/11] sched: debug cleanup place entity Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 05/11] sched buddy enable buddy logic starting at 2 running threads Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 06/11] sched: dynamic min_vruntime Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 07/11] sched rename struct task in_iowait field to sched_in_iowait Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 08/11] sched input interactivity-driven next buddy Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 09/11] sched: timer-driven " Mathieu Desnoyers
2010-08-27 18:02 ` [RFC PATCH 09/11] sched: timer-driven next buddy (update) Mathieu Desnoyers
2010-08-27 18:14 ` Thomas Gleixner
2010-08-26 18:09 ` [RFC PATCH 10/11] sched: fork expedited Mathieu Desnoyers
2010-08-26 18:09 ` [RFC PATCH 11/11] sched: fair sleepers for timer and interactive Mathieu Desnoyers
2010-08-26 18:57 ` [RFC PATCH 00/11] sched: CFS low-latency features Peter Zijlstra
2010-08-26 21:25 ` Thomas Gleixner
2010-08-26 22:22 ` Thomas Gleixner
2010-08-26 23:09 ` Mathieu Desnoyers
2010-08-26 23:36 ` Mathieu Desnoyers
2010-08-27 7:38 ` Peter Zijlstra
2010-08-27 15:23 ` Mathieu Desnoyers
2010-08-27 8:43 ` Thomas Gleixner
2010-08-27 15:50 ` Mathieu Desnoyers
2010-08-27 7:37 ` Peter Zijlstra
2010-08-27 15:21 ` Mathieu Desnoyers
2010-08-27 15:41 ` Peter Zijlstra
2010-08-27 16:09 ` Mathieu Desnoyers
2010-08-27 17:27 ` Peter Zijlstra
2010-08-27 18:32 ` Mathieu Desnoyers
2010-08-27 19:23 ` Peter Zijlstra
2010-08-27 19:57 ` Mathieu Desnoyers
2010-08-31 15:02 ` Mathieu Desnoyers
2010-08-26 23:18 ` Paul E. McKenney
2010-08-26 23:28 ` Mathieu Desnoyers
2010-08-26 23:38 ` Paul E. McKenney
2010-08-26 23:53 ` Mathieu Desnoyers
2010-08-27 0:09 ` Paul E. McKenney
2010-08-27 15:18 ` Mathieu Desnoyers
2010-08-27 15:20 ` Thomas Gleixner
2010-08-27 15:30 ` Mathieu Desnoyers
2010-08-27 15:41 ` Peter Zijlstra
2010-08-26 23:49 ` Mathieu Desnoyers
2010-08-27 7:42 ` Peter Zijlstra
2010-08-27 8:19 ` Mike Galbraith
2010-08-27 15:43 ` Mathieu Desnoyers
2010-08-27 18:38 ` Mathieu Desnoyers
2010-08-28 7:33 ` Mike Galbraith [this message]
2010-08-27 10:47 ` Indan Zupancic
2010-08-27 10:58 ` Peter Zijlstra
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=1282980839.17756.81.camel@marge.simson.net \
--to=efault@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®