Date: Thu, 17 Dec 2009 11:53:16 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Jason Garrett-Glaser <darkshikari@gmail.com>,
       Mike Galbraith <efault@gmx.de>, Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Kasper Sandberg <lkml@metanurb.dk>,
       LKML Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: x264 benchmarks BFS vs CFS
Message-ID: <20091217105316.GB26010@elte.hu>
References: <1261042383.14314.0.camel@localhost>
 <28f2fcbc0912170242r6d93dfb1j337558a829e21a75@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <28f2fcbc0912170242r6d93dfb1j337558a829e21a75@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-08-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1549
Lines: 40


* 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 
> what the conditions of this are--is it because ultrafast is just so much 
> faster than all the other modes and so switches threads/loads faster?  Is it 
> because ultrafast has relatively equal workload among the threads, unlike 
> the other loads?  We'll probably know soon.

Thanks for testing it!

Btw., you might want to make use of 'perf sched record', 'perf sched map', 
'perf sched trace' etc. to get an insight into how a particular workload 
schedules and why those decisions are done. (You'll need CONFIG_SCHED_DEBUG=y 
for best results.)

Thanks,

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