My mistake! I have checked with the mono folks and gone through the code. It turns out that the culprit is pthread_cond_timedwait() used to check for changes to the .config file. This has, apparently, been fixed in later releases/versions of mono. What level are you on?
You can verify that the culprit is as I suggest by using gdb with the -p <pid> option from root. It should stop in that API and a backtrace (bt comand) should show something like this: 0x00000200000f1aa4 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000200000f1aa4 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000800dda72 in ?? () #2 0x00000000800cf3cc in ?? () #3 0x0000000080084522 in mono_thread_manage () #4 0x000000008001f57a in mono_main () #5 0x00000200001b8598 in __libc_start_main () from /lib64/libc.so.6 #6 0x000000008001e68a in sigfillset () On 8/18/10 3:03 AM, "van Sleeuwen, Berry" <berry.vansleeu...@atosorigin.com> wrote: Neale, Did I say that? Perhaps I wasn't too clear about that. I mean powertop shows met that when the guest wakes up, mono was in about 50% of the times responsible for the wakup. Or to say it in Barton's words, 50% of the blips are from mono. Indeed using top I guess we never will see mono since it doesn't use any CPU. That's why I didn't even bother to look at top, I already expected the machine suffered from a timer instead of real work. Berry. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
