linux-kernel - Re: x264 benchmarks BFS vs CFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200912191208.57907.kernel@kolivas.org>
Date:	Sat, 19 Dec 2009 12:08:57 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	"Jason Garrett-Glaser" <darkshikari@...il.com>
Cc:	Kasper Sandberg <lkml@...anurb.dk>, Mike Galbraith <efault@....de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML Mailinglist <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: x264 benchmarks BFS vs CFS

On Fri, 18 Dec 2009 22:05:34 Jason Garrett-Glaser wrote:
> On Fri, Dec 18, 2009 at 2:57 AM, Kasper Sandberg <lkml@...anurb.dk> wrote:
> > On Fri, 2009-12-18 at 08:30 +0100, Mike Galbraith wrote:
> >> On Fri, 2009-12-18 at 06:23 +0100, Ingo Molnar wrote:
> >> > Having said that, we generally try to make things perform well without
> >> > apps having to switch themselves to SCHED_BATCH. Mike, do you think we
> >> > can make x264 perform as well (or nearly as well) under SCHED_OTHER as
> >> > under SCHED_BATCH?
> >>
> >> It's not bad as is, except for ultrafast mode.  START_DEBIT is the
> >> biggest problem there.  I don't think SCHED_OTHER will ever match
> >> SCHED_BATCH for this load, though I must say I haven't full-spectrum
> >> tested.  This load really wants RR scheduling, and wakeup preemption
> >> necessarily perturbs run order.
> >>
> >> I'll probably piddle with it some more, it's an interesting load.
> >
> > Yes, i must say, very interresting, its very complicated and... oh wait,
> > its just encoding a movie!
> 
> Your trolling is becoming a bit over-the-top at this point.  You
> should also considering replying to multiple people in one email as
> opposed to spamming a whole bunch in sequence.
> 
> Perhaps as the lead x264 developer I'm qualified to say that it
> certainly is a very complicated load due to the strict ordering
> requirements of the threading model--and that you should tone down the
> whining just a tad and perhaps read a bit more about how BFS and CFS
> work before complaining about them.

Your workload is interesting because it is a well written real world 
application with a solid threading model written in a cross platform portable 
way.  Your code is valuable as a measure for precisely this reason, and 
there's a trap in trying to program in a way that "the scheduler might like". 
That's presumably what Kasper is trying to point out, albeit in a much blunter 
fashion.

The only workloads I'm remotely interested in are real world workloads 
involving real applications like yours, software compilation, video playback, 
audio playback, gaming, apache page serving, mysql performance and so on that 
people in the real world use on real hardware all day every day. These are, of 
course, measurable even above and beyond the elusive and impossible to measure 
and quantify interactivity and responsiveness.

I couldn't care less about some artificial benchmark involving LTP, timing 
mplayer playing in the presence of 100,000 pipes, volanomark which is just a 
sched_yield benchmark, dbench and hackbench which even their original 
programmers don't like them being used as a meaningful measure, and so on, and 
normal users should also not care about the values returned by these artificial 
benchmarks when they bear no resemblance to their real world performance cases 
as above. 

I have zero interest in adding any "tweaks" to BFS to perform well in X 
benchmark, for there be a path where dragons lie. I've always maintained that, 
and still stick to it, that the more tweaks you add for corner cases, the more 
corner cases you introduce yourself. BFS will remain for a targeted audience 
and I care not to appeal to any artificial benchmarketing obsessed population 
that drives mainline, since I don't -have- to. Mainline can do what it wants, 
and hopefully uses BFS as a yardstick for comparison when appropriate.

Regards,
-- 
-ck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/