lkml.org 
[lkml]   [2000]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Auto-Adaptive scheduler - Final chapter ( the numbers ) ...
Date
From
"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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.110 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site