[Devel] Re: Do not overload dispatch queue (Was: Re: IO scheduler based IO controller V10)
Mike Galbraith
efault at gmx.de
Sat Oct 3 12:11:14 PDT 2009
On Sat, 2009-10-03 at 21:07 +0200, Mike Galbraith wrote:
> On Sat, 2009-10-03 at 19:35 +0200, Jens Axboe wrote:
> > So that's pure goodness, at least.
>
> Yeah, but it's a double edged sword, _maybe_ cut too far in the other
> direction. (impression)
>
> > > perf stat testo.sh Avg
> > > 108.12 106.33 106.34 97.00 106.52 104.8 1.000 fairness=0 overload_delay=0
> > > 93.98 102.44 94.47 97.70 98.90 97.4 .929 fairness=0 overload_delay=1
> > > 90.87 95.40 95.79 93.09 94.25 93.8 .895 fairness=1 overload_delay=0
> > > 89.93 90.57 89.13 93.43 93.72 91.3 .871 fairness=1 overload_delay=1
> > > 89.81 88.82 91.56 96.57 89.38 91.2 .870 desktop=1 +last_end_sync
> > > 92.61 94.60 92.35 93.17 94.05 93.3 .890 block-for-linus
> >
> > Doesn't look too bad, all things considered. Apart from "stock" cfq,
> > it's consistent. And being consistent is a Good Thing. Performance wise,
> > it's losing out to "stock" but looks pretty competetive otherwise.
>
> No, not bad at all, still a large win over stock.
>
> > So far that looks like a winner. The dictator wanted good latency, he's
> > getting good latency. I'll continue working on this on monday, while I'm
> > waiting for delivery of the Trabant.
>
> I'm unsure feel wise. Disk is sounding too seeky, which worries me.
But, this is a _huge_ improvement of the dd vs reader thing regardless
of any further tweaking that may or may not prove necessary. That ages
old corner case seems to be defeated.
-Mike
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list