Thursday, January 27, 2000 6:10 PM
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 :
vmstat of a "lat_ctx -s 0 20" give no more than 5-6 tasks in RQ
vmstat of a "threads 20 xx" give always an RQ = 20 ( with no need of cost
compensation )
Now, as even my sister ( that works in business ) can realize this code is
stored entirely in cache, and the write to the counter is onto the process
stack.
I _want_ this behaviour coz I _want_ a measure of clean switching times by
keeping
cache issues ot of the test.
</DONTSPLITTHIS>
Anyway adding a cache footprint into the two cases will add a constant term
that minimize
even more the percent result.
Davide.
-- All this stuff is IMVHO- 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:18 EST