From: Con Kolivas <kernel@kolivas.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Nikos Chantziaras <realnc@arcor.de>, Ingo Molnar <mingo@elte.hu>,
Mike Galbraith <efault@gmx.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org
Subject: Re: BFS vs. mainline scheduler benchmarks and measurements
Date: Thu, 10 Sep 2009 11:02:56 +1000 [thread overview]
Message-ID: <200909101102.56615.kernel@kolivas.org> (raw)
In-Reply-To: <20090909205043.GI18599@kernel.dk>
On Thu, 10 Sep 2009 06:50:43 Jens Axboe wrote:
> On Wed, Sep 09 2009, Nikos Chantziaras wrote:
> > On 09/09/2009 09:04 PM, Ingo Molnar wrote:
> >> [...]
> >>
> >> * Jens Axboe<jens.axboe@oracle.com> wrote:
> >>> On Wed, Sep 09 2009, Jens Axboe wrote:
> >>> [...]
> >>> BFS210 runs on the laptop (dual core intel core duo). With make -j4
> >>> running, I clock the following latt -c8 'sleep 10' latencies:
> >>>
> >>> -rc9
> >>>
> >>> Max 17895 usec
> >>> Avg 8028 usec
> >>> Stdev 5948 usec
> >>> Stdev mean 405 usec
> >>>
> >>> Max 17896 usec
> >>> Avg 4951 usec
> >>> Stdev 6278 usec
> >>> Stdev mean 427 usec
> >>>
> >>> Max 17885 usec
> >>> Avg 5526 usec
> >>> Stdev 6819 usec
> >>> Stdev mean 464 usec
> >>>
> >>> -rc9 + mike
> >>>
> >>> Max 6061 usec
> >>> Avg 3797 usec
> >>> Stdev 1726 usec
> >>> Stdev mean 117 usec
> >>>
> >>> Max 5122 usec
> >>> Avg 3958 usec
> >>> Stdev 1697 usec
> >>> Stdev mean 115 usec
> >>>
> >>> Max 6691 usec
> >>> Avg 2130 usec
> >>> Stdev 2165 usec
> >>> Stdev mean 147 usec
> >>
> >> At least in my tests these latencies were mainly due to a bug in
> >> latt.c - i've attached the fixed version.
> >>
> >> The other reason was wakeup batching. If you do this:
> >>
> >> echo 0> /proc/sys/kernel/sched_wakeup_granularity_ns
> >>
> >> ... then you can switch on insta-wakeups on -tip too.
> >>
> >> With a dual-core box and a make -j4 background job running, on
> >> latest -tip i get the following latencies:
> >>
> >> $ ./latt -c8 sleep 30
> >> Entries: 656 (clients=8)
> >>
> >> Averages:
> >> ------------------------------
> >> Max 158 usec
> >> Avg 12 usec
> >> Stdev 10 usec
> >
> > With your version of latt.c, I get these results with 2.6-tip vs
> > 2.6.31-rc9-bfs:
> >
> >
> > (mainline)
> > Averages:
> > ------------------------------
> > Max 50 usec
> > Avg 12 usec
> > Stdev 3 usec
> >
> >
> > (BFS)
> > Averages:
> > ------------------------------
> > Max 474 usec
> > Avg 11 usec
> > Stdev 16 usec
> >
> >
> > However, the interactivity problems still remain. Does that mean it's
> > not a latency issue?
>
> It probably just means that latt isn't a good measure of the problem.
> Which isn't really too much of a surprise.
And that's a real shame because this was one of the first real good attempts
I've seen to actually measure the difference, and I thank you for your
efforts Jens. I believe the reason it's limited is because all you're
measuring is time from wakeup and the test app isn't actually doing any work.
The issue is more than just waking up as fast as possible, it's then doing
some meaningful amount of work within a reasonable time frame as well. What
the "meaningful amount of work" and "reasonable time frame" are, remains a
mystery, but I guess could be added on to this testing app.
What does please me now, though, is that this message thread is finally
concentrating on what BFS was all about. The fact that it doesn't scale is no
mystery whatsoever. The fact that that throughput and lack of scaling was
what was given attention was missing the point entirely. To point that out I
used the bluntest response possible, because I know that works on lkml (does
it not?). Unfortunately I was so blunt that I ended up writing it in another
language; Troll. So for that, I apologise.
The unfortunate part is that BFS is still far from a working, complete state,
yet word got out that I had "released" something, which I had not, but
obviously there's no great distinction between putting something on a server
for testing, and a real release with an announce.
BFS is a scheduling experiment to demonstrate what effect the cpu scheduler
really has on the desktop and how it might be able to perform if we design
the scheduler for that one purpose.
It pleases me immensely to see that it has already spurred on a flood of
changes to the interactivity side of mainline development in its few days of
existence, including some ideas that BFS uses itself. That in itself, to me,
means it has already started to accomplish its goal, which ultimately, one
way or another, is to improve what the CPU scheduler can do for the linux
desktop. I can't track all the sensitive areas of the mainline kernel
scheduler changes without getting involved more deeply than I care to so it
would be counterproductive of me to try and hack on mainline. I much prefer
the quieter inbox.
If people want to use BFS for their own purposes or projects, or even better
help hack on it, that would make me happy for different reasons. I will
continue to work on my little project -in my own time- and hope that it
continues to drive further development of the mainline kernel in its own way.
We need more experiments like this to question what we currently have and
accept. Other major kernel subsystems are no exception.
Regards,
--
-ck
<code before rhetoric>
next prev parent reply other threads:[~2009-09-10 1:34 UTC|newest]
Thread overview: 224+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-06 20:59 BFS vs. mainline scheduler benchmarks and measurements Ingo Molnar
2009-09-07 2:05 ` Frans Pop
2009-09-07 12:16 ` [quad core results] " Ingo Molnar
2009-09-07 12:36 ` Stefan Richter
2009-09-07 13:41 ` Markus Tornqvist
2009-09-07 13:59 ` Ingo Molnar
2009-09-09 5:54 ` Markus Tornqvist
2009-09-07 14:45 ` Arjan van de Ven
2009-09-07 15:20 ` Frans Pop
2009-09-07 15:36 ` Arjan van de Ven
2009-09-07 15:47 ` Frans Pop
2009-09-07 15:24 ` Xavier Bestel
2009-09-07 15:37 ` Arjan van de Ven
2009-09-07 16:00 ` Diego Calleja
2009-09-07 15:34 ` Nikos Chantziaras
2009-09-07 3:38 ` Nikos Chantziaras
2009-09-07 11:01 ` Frederic Weisbecker
2009-09-08 18:15 ` Nikos Chantziaras
2009-09-10 20:25 ` Frederic Weisbecker
2009-09-07 14:40 ` Arjan van de Ven
2009-09-08 7:19 ` Nikos Chantziaras
2009-09-08 8:31 ` Arjan van de Ven
2009-09-08 20:22 ` Frans Pop
2009-09-08 21:10 ` Michal Schmidt
2009-09-08 21:11 ` Frans Pop
2009-09-08 21:40 ` GeunSik Lim
2009-09-08 22:36 ` Frans Pop
2009-09-09 9:53 ` Benjamin Herrenschmidt
2009-09-09 11:14 ` David Newall
2009-09-09 11:32 ` Benjamin Herrenschmidt
2009-09-09 11:55 ` Frans Pop
2009-09-11 1:36 ` Benjamin Herrenschmidt
2009-09-16 18:27 ` Frans Pop
2009-09-17 1:29 ` Benjamin Herrenschmidt
2009-10-01 9:36 ` Frans Pop
2009-09-08 8:38 ` Arjan van de Ven
2009-09-08 10:13 ` Nikos Chantziaras
2009-09-08 11:32 ` Juergen Beisert
2009-09-08 22:00 ` Nikos Chantziaras
2009-09-08 23:20 ` Jiri Kosina
2009-09-08 23:38 ` Nikos Chantziaras
2009-09-08 12:03 ` Theodore Tso
2009-09-08 21:28 ` Nikos Chantziaras
2009-09-08 14:20 ` Arjan van de Ven
2009-09-08 22:53 ` Nikos Chantziaras
2009-09-07 23:54 ` Thomas Fjellstrom
2009-09-08 11:30 ` Nikos Chantziaras
2009-09-07 3:50 ` Con Kolivas
2009-09-07 18:20 ` Jerome Glisse
2009-09-07 9:49 ` Jens Axboe
2009-09-07 10:12 ` Nikos Chantziaras
2009-09-07 10:41 ` Jens Axboe
2009-09-07 11:57 ` Jens Axboe
2009-09-07 14:14 ` Ingo Molnar
2009-09-07 17:38 ` Jens Axboe
2009-09-07 20:44 ` Jens Axboe
2009-09-08 9:13 ` Jens Axboe
2009-09-08 15:23 ` Peter Zijlstra
2009-09-08 20:34 ` Jens Axboe
2009-09-09 6:13 ` Ingo Molnar
2009-09-09 8:34 ` Nikos Chantziaras
2009-09-09 8:52 ` Mike Galbraith
2009-09-09 9:02 ` Peter Zijlstra
2009-09-09 9:18 ` Mike Galbraith
2009-09-09 9:05 ` Nikos Chantziaras
2009-09-09 9:17 ` Peter Zijlstra
2009-09-09 9:40 ` Nikos Chantziaras
2009-09-09 10:17 ` Nikos Chantziaras
2009-09-10 19:45 ` Martin Steigerwald
2009-09-10 20:06 ` Ingo Molnar
2009-09-10 20:39 ` Martin Steigerwald
2009-09-10 20:42 ` Ingo Molnar
2009-09-10 21:19 ` Martin Steigerwald
2009-09-11 9:26 ` Mat
2009-09-12 11:26 ` Martin Steigerwald
2009-09-09 9:10 ` Jens Axboe
2009-09-09 11:54 ` Jens Axboe
2009-09-09 12:20 ` Jens Axboe
2009-09-09 18:04 ` Ingo Molnar
2009-09-09 20:12 ` Nikos Chantziaras
2009-09-09 20:50 ` Jens Axboe
2009-09-10 1:02 ` Con Kolivas [this message]
2009-09-10 11:03 ` Jens Axboe
2009-09-10 3:15 ` Mike Galbraith
2009-09-10 6:08 ` Ingo Molnar
2009-09-10 6:40 ` Ingo Molnar
2009-09-10 9:54 ` Jens Axboe
2009-09-10 10:03 ` Ingo Molnar
2009-09-10 10:11 ` Jens Axboe
2009-09-10 10:28 ` Jens Axboe
2009-09-10 10:57 ` Mike Galbraith
2009-09-10 11:09 ` Jens Axboe
2009-09-10 11:21 ` Mike Galbraith
2009-09-10 11:24 ` Jens Axboe
2009-09-10 11:28 ` Mike Galbraith
2009-09-10 11:35 ` Jens Axboe
2009-09-10 11:42 ` Mike Galbraith
2009-09-10 16:02 ` Bret Towe
2009-09-10 16:05 ` Peter Zijlstra
2009-09-10 16:12 ` Bret Towe
2009-09-10 16:26 ` Ingo Molnar
2009-09-10 16:33 ` Bret Towe
2009-09-10 17:03 ` Ingo Molnar
2009-09-10 17:53 ` Nikos Chantziaras
2009-09-10 18:46 ` Ingo Molnar
2009-09-10 18:51 ` [tip:sched/core] sched: Disable NEW_FAIR_SLEEPERS for now tip-bot for Ingo Molnar
2009-09-10 18:57 ` [tip:sched/core] sched: Fix sched::sched_stat_wait tracepoint field tip-bot for Ingo Molnar
2009-09-10 9:48 ` BFS vs. mainline scheduler benchmarks and measurements Jens Axboe
2009-09-10 9:59 ` Ingo Molnar
2009-09-10 10:01 ` Jens Axboe
2009-09-10 6:55 ` Peter Zijlstra
2009-09-10 6:58 ` Jens Axboe
2009-09-10 7:04 ` Ingo Molnar
2009-09-10 9:44 ` Jens Axboe
2009-09-10 9:45 ` Jens Axboe
2009-09-10 13:53 ` Steven Rostedt
2009-09-10 7:33 ` Jens Axboe
2009-09-10 7:49 ` Ingo Molnar
2009-09-10 7:53 ` Jens Axboe
2009-09-10 10:02 ` Ingo Molnar
2009-09-10 10:09 ` Jens Axboe
2009-09-10 18:00 ` [crash, bisected] Re: clocksource: Resolve cpu hotplug dead lock with TSC unstable Ingo Molnar
2009-09-11 7:37 ` Ingo Molnar
2009-09-11 7:48 ` Martin Schwidefsky
2009-09-11 13:33 ` Martin Schwidefsky
2009-09-11 18:22 ` [tip:timers/core] clocksource: Resolve cpu hotplug dead lock with TSC unstable, fix crash tip-bot for Martin Schwidefsky
2009-09-14 15:19 ` [crash, bisected] Re: clocksource: Resolve cpu hotplug dead lock with TSC unstable Ingo Molnar
2009-09-14 15:37 ` Martin Schwidefsky
2009-09-14 17:59 ` Martin Schwidefsky
2009-09-10 6:59 ` BFS vs. mainline scheduler benchmarks and measurements Ingo Molnar
2009-09-09 12:48 ` Mike Galbraith
2009-09-09 15:37 ` [tip:sched/core] sched: Turn off child_runs_first tip-bot for Mike Galbraith
2009-09-09 17:57 ` Theodore Tso
2009-09-09 18:08 ` Ingo Molnar
2009-09-09 18:59 ` Chris Friesen
2009-09-09 19:48 ` Pavel Machek
2009-09-09 15:37 ` [tip:sched/core] sched: Re-tune the scheduler latency defaults to decrease worst-case latencies tip-bot for Mike Galbraith
2009-09-12 11:45 ` Martin Steigerwald
2009-09-09 15:37 ` [tip:sched/core] sched: Keep kthreads at default priority tip-bot for Mike Galbraith
2009-09-09 16:55 ` Dmitry Torokhov
2009-09-09 17:06 ` Peter Zijlstra
2009-09-09 17:34 ` Mike Galbraith
2009-09-12 11:48 ` Martin Steigerwald
2009-09-12 12:19 ` Mike Galbraith
2009-09-09 11:52 ` BFS vs. mainline scheduler benchmarks and measurements Nikos Chantziaras
2009-09-07 18:02 ` Avi Kivity
2009-09-07 18:46 ` Jens Axboe
2009-09-07 20:36 ` Ingo Molnar
2009-09-07 20:46 ` Jens Axboe
2009-09-07 21:03 ` Peter Zijlstra
2009-09-07 21:05 ` Jens Axboe
2009-09-07 22:18 ` Ingo Molnar
2009-09-09 7:38 ` Pavel Machek
2009-09-10 12:19 ` latt location (Was Re: BFS vs. mainline scheduler benchmarks and measurements) Jens Axboe
2009-09-07 15:16 ` BFS vs. mainline scheduler benchmarks and measurements Michael Buesch
2009-09-07 18:26 ` Ingo Molnar
2009-09-07 18:47 ` Daniel Walker
2009-09-07 18:51 ` Michael Buesch
2009-09-07 20:57 ` Ingo Molnar
2009-09-07 23:24 ` Pekka Pietikainen
2009-09-08 8:04 ` Ingo Molnar
2009-09-08 8:13 ` Nikos Chantziaras
2009-09-08 10:12 ` Ingo Molnar
2009-09-08 10:40 ` Nikos Chantziaras
2009-09-08 11:35 ` Ingo Molnar
2009-09-08 19:06 ` Nikos Chantziaras
2009-09-08 12:00 ` el_es
2009-09-08 15:45 ` Michael Buesch
2009-09-08 7:48 ` Ingo Molnar
2009-09-08 9:50 ` Benjamin Herrenschmidt
2009-09-08 13:09 ` Ralf Baechle
2009-09-09 1:36 ` Felix Fietkau
2009-09-08 13:09 ` Felix Fietkau
2009-09-09 0:28 ` Benjamin Herrenschmidt
2009-09-09 0:37 ` David Miller
2009-09-08 14:45 ` Michael Buesch
2009-09-18 11:24 ` Ingo Molnar
2009-09-18 14:46 ` Felix Fietkau
2009-09-19 18:01 ` Ingo Molnar
2009-09-19 18:43 ` Felix Fietkau
2009-09-19 19:39 ` Ingo Molnar
2009-09-19 20:15 ` Felix Fietkau
2009-09-19 20:22 ` Ingo Molnar
2009-09-19 20:33 ` Felix Fietkau
2009-09-20 18:10 ` Ingo Molnar
2009-09-08 12:57 ` Epic regression in throughput since v2.6.23 Serge Belyshev
2009-09-08 17:47 ` Jesse Brandeburg
2009-09-08 18:20 ` Nikos Chantziaras
2009-09-08 19:00 ` Jeff Garzik
2009-09-08 19:20 ` Serge Belyshev
2009-09-08 19:26 ` Jeff Garzik
2009-09-08 18:37 ` Nikos Chantziaras
2009-09-08 22:15 ` Serge Belyshev
2009-09-09 15:52 ` Ingo Molnar
2009-09-09 20:49 ` Serge Belyshev
2009-09-09 21:23 ` Cory Fields
2009-09-10 6:53 ` Ingo Molnar
2009-09-10 23:23 ` Serge Belyshev
2009-09-11 6:10 ` Ingo Molnar
2009-09-11 8:55 ` Serge Belyshev
2009-09-13 15:27 ` Serge Belyshev
2009-09-13 15:47 ` Ingo Molnar
2009-09-13 19:17 ` Mike Galbraith
2009-09-14 6:15 ` Mike Galbraith
2009-09-16 19:45 ` Ingo Molnar
2009-09-16 23:18 ` Serge Belyshev
2009-09-17 4:55 ` [patchlet] " Mike Galbraith
2009-09-17 5:06 ` Mike Galbraith
2009-09-17 7:21 ` Ingo Molnar
2009-09-10 7:43 ` [updated] BFS vs. mainline scheduler benchmarks and measurements Ingo Molnar
2009-09-14 9:46 ` Phoronix CFS vs BFS bencharks Nikos Chantziaras
2009-09-14 11:35 ` Mike Galbraith
[not found] ` <f42384a10909140727k463ff460q3859892dcb79bcc5@mail.gmail.com>
2009-09-14 15:32 ` Mike Galbraith
2009-09-14 19:14 ` Marcin Letyns
2009-09-14 20:49 ` Willy Tarreau
2009-09-15 8:37 ` Mike Galbraith
2009-09-10 21:17 BFS vs. mainline scheduler benchmarks and measurements Martin Steigerwald
2009-09-11 10:10 Mat
2009-09-11 18:33 Volker Armin Hemmann
2009-09-12 7:37 ` Nikos Chantziaras
2009-09-12 7:51 ` Arjan van de Ven
2009-09-12 8:27 ` Volker Armin Hemmann
2009-09-12 9:03 ` Nikos Chantziaras
2009-09-12 9:34 ` Volker Armin Hemmann
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=200909101102.56615.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=realnc@arcor.de \
/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.