Alexander Viro writes:
> BTW, what spinlocks get contention in variant without BKL? And what about
> comparison between the BKL and non-BKL versions? If it's something like
> BKL no BKL
> 4-way 50 20
> 8-way 30 30
> - something is certainly wrong, but restoring the BKL is _not_ a win.
the measured performance is:
4way->8way
2.4.0-test1 2816->3702 (31%up)
2.4.0-test8 4006->5287 (63%up)
2.4.0-test9 3669->2193 (40%down)
So, roughly speaking,
BKL no BKL
4-way 40 36
8-way 53 22
- Above are the comparison between test8 and test9.
Test9 with BKL shows 5249 @8way, nearly equal to test8 @8way.
> scenarios, but... Seriously, folks, could you compare the 4 variants above
> and gather the contention data for the -test9 on your loads? That would help
> a lot.
What kind of contention data you requested?
* kernel-lock spining time
* semaphore task switching time
...
Now, I understand the difference of test8 and test9.
test8 uses kernel_lock() to protect critical region,
test9 uses up/down semaphor for that.
FYI, I resend following data again.
> The following table shows one minute average of "vmstat 1".
>
> configuration Req/s | r b intr c-sw user os idle
> ------------------------+--------------------------------------------------
> 2.4.0t1 4cpu 2816 | 60 0 28877 5103 18 82 0
> 8cpu 3702 | 37 0 33495 16387 14 86 0
> 2.4.0t8 4cpu 4066 | 57 0 38743 8674 27 73 0
> 8cpu 5287 | 33 0 40755 30626 21 78 0
> 2.4.0t9 4cpu 3669 | 53 3 35822 18898 25 73 2
> 8cpu 2193 | 5 8 22114 94609 9 52 39
context switch count on test9 is 2-3 times bigger.
And, using the above table, average transaction time and its
breakdowns can be calculated as follows.
time/req USER OS IDLE
2.4.0t1 4cpu 1.42ms | 0.26ms 1.16ms 0ms
8cpu 2.16ms | 0.30ms 1.85ms 0ms
2.4.0t8 4cpu 0.98ms | 0.26ms 0.72ms 0ms
8cpu 1.44ms | 0.30ms 1.12ms 0ms
2.4.0t9 4cpu 1.09ms | 0.27ms 0.80ms 0.02ms
8cpu 3.65ms | 0.33ms 1.90ms 1.42ms
Test9 needs longer OS time than test8, especialy on 8cpu (80% longer).
Test9 needs longer USER time than test8 on 8cpu.
Test9 idle too much.
Frequent context switchs eat OS time.
Frequent process migrations eat USER time.
I think, the critical region is too small to be protected by semaphor
and task-switch.
-- Computer Systems Laboratory, Fujitsu Labs. kumon@flab.fujitsu.co.jp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:20 EST