Re: x264 benchmarks BFS vs CFS

[Ingo Molnar]

* Jason Garrett-Glaser <darkshikari@xxxxxxxxx> wrote:

> On Thu, Dec 17, 2009 at 3:00 AM, Kasper Sandberg <lkml@xxxxxxxxxxx> wrote:
> > On Thu, 2009-12-17 at 11:53 +0100, Ingo Molnar wrote:
> >> * Jason Garrett-Glaser <darkshikari@xxxxxxxxx> wrote:
> >>
> >> > On Thu, Dec 17, 2009 at 1:33 AM, Kasper Sandberg <lkml@xxxxxxxxxxx> 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.
> 
> Can't individually applications request SCHED_BATCH?  Our plan was to have 
> x264 simply detect if it was necessary (once we figure out what encoding 
> settings result in the large gap situation) and automatically enable it for 
> the current application.

Yeah, SCHED_BATCH can be requested at will by an app. It's an unprivileged 
operation. It gets passed down to child tasks. (You can just do it 
unconditionally - older kernels will ignore it and give you an error code for 
setscheduler call.)

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?

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