Thursday, January 27, 2000 6:34 PM
Larry McVoy <lm@bitmover.com> wrote :
> : > . the real measure of any change is whether or not it increases or
> : > decreases the amount of code in the icache, the number of
> : mispredicted
> : > branches in the icache, the amount of data in the dcache, and
> : finally,
> : > any changes in the number of cache misses.
> :
> : This is the code [etc]
>
> And that code doesn't answer any of the questions posed above. Not one.
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:18 EST