interesting. Could you try two things? Firstly, could you add some
minimal delays to the lock/unlock path, of at least 1 usec? E.g.
"synchro-test.ko load=1 interval=1". [but you could try longer delays
too, 10 usecs is still realistic.]
Graphs attached. The summary for those who don't like to look at attachments is
that the mutex fastpath (threads 1) that I sent the optimized patch for is
comparable within the margin of error to semaphores. The mutex common path
(threads > 1) gets embarrassed by semaphores. So mutexes common paths are not
yet ready as far as ppc64 is concerned.
secondly, could you try the VFS creat+unlink test via the test-mutex.c
code below, with something like:
./test-mutex V 16 10
Queued into my todo list.
thirdly, could you run 'vmstat 1' during the tests, and post those lines
too? Here i'm curious about two things: the average runqueue length
(whether we have overscheduling), and CPU utilization and idle time left
(how efficiently cycles are preserved in contention). [btw., does ppc
have an idle=poll equivalent mode of idling?]
Also queued in my todo list.
also, there seems to be some fluctuation in the numbers - could you try
to run a few more to see how stable the numbers are?
For the graphs the line is the average of 5 runs, and the 5 runs are scatter
plotted as well.
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]