Sorry Larry but You've the patch ( code ) and the "instrument" ( code ) used
for test.
More You have numbers that show switching times differences.
I can optimize the patch to perform even better for RQ = 2 ( move some code
out of fast path )
but I think it makes no sense due to the fact that the scheduler must have a
faster responses
under high loads.
Even if I've changed the scheduler to better perform with short RQ ( and the
numbers are here ),
I still think that speaking about RQ = 2 in analyzing a scheduler is a
nonsense.
An RQ = 2, under real charge ( if You've 2 running tasks probably Your
system is not so stressed )
switch at no more than 2000 switch / sec ( statistically even less ), so to
get a 5% of scheduler time
You need a switch time of 25 us.
This is a time that I get with RQ = 100-150 on my machine.
You can state that exist machines ( slow ) in which 25 us is a typical
switch time ( for RQ = 2 ),
but probably that machines cannot perform 2000 switch / sec under real load.
As an example my machine ( PII 400 ) with RQ = 2 has a switch time = 1.36 us
( with the patch ),
so You need a machine 18.5 times slower than mine.
> for size in 0 2 4 8 10 12 14 16 18 20 22 24 26 28 30 32
> do lat_ctx -s $size 2 2 2 2 2 2
> done
>
> plot the results. If your L1 cache is bigger than 32K, keep going.
I'll do for sure even if I think that, as I've said to Horst, this will add
a constant
term that will reduce even more the percent result.
PS:
Tonight ( Europe ) I can't coz I'm out for dinner, I'll run the test
tomorrow night.
With respect,
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/