RE: [suse-programming-e] Problems with POSIX Asynchronous IO
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 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. 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? $ rpm -q kernel-default kernel-default-2.6.5-7.108 $ rpm -q glibc glibc-2.3.3-97 -----Original Message----- From: Matthew Gregan [mailto:kinetik@orcon.net.nz] Sent: 28. september 2004 00:38 To: suse-programming-e@suse.com Subject: Re: [suse-programming-e] Problems with POSIX Asynchronous IO At 2004-09-27T11:50:28+0200, Hallingstad Håkon wrote:
FYI: aiotest is working fine on my SuSE 9.1 Personal box.
Interesting, thanks for testing that. I've just done a minimal SuSE 9.1 install and do see the problem, even after updating to the latest available SuSE kernel. What versions of glibc and the kernel does you 9.1 box have, is your 9.1 box a i686 or better (or some other system where the TLS glibc libraries will be used), and are you running a SuSE kernel? $ rpm -q kernel-default; rpm -q glibc kernel-default-2.6.5-7.108 glibc-2.3.3-97 Thanks, -mjg
-----Original Message----- From: Matthew Gregan [mailto:kinetik@orcon.net.nz] Sent: 27. september 2004 11:33 To: suse-programming-e@suse.com Subject: [suse-programming-e] Problems with POSIX Asynchronous IO
Hi all,
I'm having some problems with the POSIX Asynchronous IO support on a SLES 9 box I've been working with. The machine has all of the available SLES 9 updates applied.
After submitting a single IO using the POSIX AIO interface provided by glibc, I notice that the worker thread created by glibc enters a tight loop and consumes 100% of one CPU. Once this occurs, AIO continues to work fine (other than this problem), but the worker thread will remain in this state until the program exits.
-- Matthew Gregan |/ /| kinetik@orcon.net.nz -- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e
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
participants (2)
-
Hallingstad Håkon
-
Matthew Gregan