"Davide Libenzi" <davidel@maticad.it> said:
> Horst von Brand <vonbrand@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@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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:19 EST