All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kasper Sandberg <lkml@metanurb.dk>
To: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>,
	Jason Garrett-Glaser <darkshikari@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	LKML Mailinglist <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: x264 benchmarks BFS vs CFS
Date: Fri, 18 Dec 2009 11:54:18 +0100	[thread overview]
Message-ID: <1261133658.14314.33.camel@localhost> (raw)
In-Reply-To: <1261056647.10838.26.camel@marge.simson.net>

On Thu, 2009-12-17 at 14:30 +0100, Mike Galbraith wrote:
> On Thu, 2009-12-17 at 12:00 +0100, Kasper Sandberg wrote:
> > On Thu, 2009-12-17 at 11:53 +0100, Ingo Molnar wrote:
> > > * Jason Garrett-Glaser <darkshikari@gmail.com> wrote:
> > > 
> > > > On Thu, Dec 17, 2009 at 1:33 AM, Kasper Sandberg <lkml@metanurb.dk> wrote:
> > > > > well well :) nothing quite speaks out like graphs..
> > > > >
> > > > > http://doom10.org/index.php?topic=78.0
> > > > >
> > > > >
> > > > >
> > > > > regards,
> > > > > Kasper Sandberg
> > > > 
> > > > Yeah, I sent this to Mike a bit ago.  Seems that .32 has basically tied 
> > > > it--and given the strict thread-ordering expectations of x264, you basically 
> > > > can't expect it to do any better, though I'm curious what's responsible for 
> > > > the gap in "veryslow", even with SCHED_BATCH enabled.
> > > > 
> > > > The most odd case is that of "ultrafast", in which CFS immediately ties BFS 
> > > > when we enable SCHED_BATCH.  We're doing some further testing to see exactly 
> > 
> > Thats kinda besides the point.
> > 
> > all these tunables and weirdness is _NEVER_ going to work for people.
> 
> Fact is, it is working for a great number of people, the vast majority
> of whom don't even know where the knobs are, much less what they do. 
but not as great as it could be :)

> 
> > now forgive me for being so blunt, but for a user, having to do
> > echo x264 > /proc/cfs/gief_me_performance_on_app
> > or
> > echo some_benchmark > x264 > /proc/cfs/gief_me_performance_on_app
> 
> Theatrics noted.
> 
> > just isnt usable, bfs matches, even exceeds cfs on all accounts, with
> > ZERO user tuning, so while cfs may be able to nearly match up with a ton
> > of application specific stuff, that just doesnt work for a normal user.
> 
> Seems you haven't done much benchmarking.  BFS has strengths as well as
> weaknesses, all schedulers do.
yeah, BFS just has more strengths and fewer weaknesses than CFS :)
> 
> > not to mention that bfs does this whilst not loosing interactivity,
> > something which cfs certainly cannot boast.
> 
> Not true.  I sent Con hard evidence of a severe problem area wrt
> interactivity, and hard numbers showing other places where BFS needs
> some work.  But hey, if BFS blows your skirt up, use it and be happy.
Theatrics noted.

As for your point, well.. as far as i have heard, all you've come up
with is COMPLETELY WORTHLESS use cases which nobody is ever EVAR going
to do, and thus irellevant
> 
> 	-Mike
> 


  reply	other threads:[~2009-12-18 10:54 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-17  9:33 x264 benchmarks BFS vs CFS Kasper Sandberg
2009-12-17 10:42 ` Jason Garrett-Glaser
2009-12-17 10:53   ` Ingo Molnar
2009-12-17 11:00     ` Kasper Sandberg
2009-12-17 12:08       ` Ingo Molnar
2009-12-17 12:35         ` Kasper Sandberg
2009-12-17 15:47         ` Arjan van de Ven
2009-12-17 13:30       ` Mike Galbraith
2009-12-18 10:54         ` Kasper Sandberg [this message]
2009-12-18 11:41           ` Mike Galbraith
2009-12-17 21:22       ` Thomas Fjellstrom
2009-12-18 10:56         ` Kasper Sandberg
2009-12-18  1:18       ` Jason Garrett-Glaser
2009-12-18  5:23         ` Ingo Molnar
2009-12-18  7:30           ` Mike Galbraith
2009-12-18 10:11             ` Jason Garrett-Glaser
2009-12-18 12:49               ` Mike Galbraith
2009-12-18 13:06                 ` Ingo Molnar
2009-12-18 13:36                   ` Mike Galbraith
2009-12-18 13:53                 ` Mike Galbraith
2009-12-18 10:57             ` Kasper Sandberg
2009-12-18 11:05               ` Jason Garrett-Glaser
2009-12-19  1:08                 ` Con Kolivas
2009-12-19  4:03                   ` Mike Galbraith
2009-12-19 17:36                     ` Kasper Sandberg
2009-12-19 20:57                       ` Mike Galbraith
2009-12-20  3:22                       ` Andres Freund
2009-12-20 12:10                         ` Kasper Sandberg
2009-12-20 13:09                           ` Kasper Sandberg
2009-12-20 15:13                           ` Mike Galbraith
2009-12-20 15:51                             ` Mike Galbraith
2009-12-22  7:33                               ` Jason Garrett-Glaser
2009-12-22  7:39                                 ` Jason Garrett-Glaser
2009-12-18 10:56         ` Kasper Sandberg

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=1261133658.14314.33.camel@localhost \
    --to=lkml@metanurb.dk \
    --cc=a.p.zijlstra@chello.nl \
    --cc=darkshikari@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.