Auto-Adaptive scheduler - Final chapter ( the numbers ) ...
Horst von Brand
vonbrand en sleipnir.valparaiso.cl
Jue Ene 27 22:14:23 CST 2000
"Davide Libenzi" <davidel en maticad.it> said:
> Horst von Brand <vonbrand en pincoya.inf.utfsm.cl> wrote :
> > As was said here time and again: This is ridiculously unrealistic. Your
> > benchmark plus whatever scheduler you use fits in the smallest cache. Use
> > some code that is some 2 or 3Kb at least between schedules, and run
> > _different_ code each time. I'd bet you see quite different numbers that
> way.
> These are my words in Larry answer :
>
> <DONTSPLITTHIS>
> This is a pure switching time test.
> It is a _real_ switching test, that can be used to test switching times
> under _certain_
> RQ loads :
Exactly. Something that _never_ happens in real life.
[...]
> Anyway adding a cache footprint into the two cases will add a constant term
> that minimize
> even more the percent result.
No. Your scheduler dirties the cache much more than the standard one, so it
will blow out much more of the application (and get blown out of cache more
too). Most probably just one cache miss kills all your advantage (if there
is one at all, Larry has said that a 3% difference could be due just to
random factors).
Sure, pure swichting time is a nice number to quote, but it has no
significance for real life.
--
Horst von Brand vonbrand en sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Más información sobre la lista de distribución Ayuda