At 2004-09-28T12:58:01+0200, Hallingstad Håkon wrote:
I found out although aiotest does not use much CPU, it does generate a lot of io_getevents.
$ strace -f ./aiotest 2> aiotest.stderr & [1] 22004 $ check CPU utilisation $ ps -e -L -o pcpu,pid,tid,comm,wchan | grep aiotest 0.0 22005 22005 aiotest schedule_timeout 0.0 22005 22006 aiotest ptrace_notify $ [1]+ Done strace -f ./aiotest 2> aiotest.stderr $ grep 'io_getevents(0x4017a000, 0, 0xa, 0x4038394c, 0) = 0' aiotest.stderr | wc --lines 1900804
Yes, that's the io_getevents syscall inside handle_kernel_aio, which is where I can see the worker thread spinning when my test case is running.
1. I ran top with an update every second, and it confirms that aiotest uses 0.0% of the CPU. I have a 2.8 GHz Pentium 4 machine.
Oh! Now I understand why you didn't see high CPU utilisation. top(1) is broken in this respect--for some reason it's not counting CPU utilisation (and presumably other resource utilisation) by threads other than the first/main one, at least in the case of this test case. This problem occurs on SLES 9 as well... I haven't had time to look into it much further yet, but I guess it's worth opening a bug to SuSE about it. Try using vmstat(1) or ps(1) in show-all-threads mode instead. It sounds like the problem does occur on your machine, so I expect if you rerun the test and watch the CPU using vmstat, you'll see the high CPU utilisation.
2. The number of io_getevents increases proportionally to the sleep-period, with about 19 calls per milliseconds.
I guess the 19 io_getevents per ms is too CPU intensive for your machine?
Given that I now believe the problem occurs on your SuSE 9.1 install as well, I think you'll find that the number of io_getevents calls increases in proportion to the speed of CPU, i.e. the faster the CPU, the faster handle_kernel_aio will spin. I appreciate your time testing this for me. Thanks, -mjg -- Matthew Gregan |/ /| kinetik@orcon.net.nz