> This phenomenon appears to be caused by some interaction between the > delivery of I/O interrupts and timer interrupts when running under > VM (or LPAR with shared CPUs, for that matter). We haven't quite > understood this whole issue yet, unfortunately. (Maybe Martin knows > more details ...)
Unfortunatly no. I havent't found a way to counter this problem yet. Seems like the virtualization (VM/LPAR) likes to "cluster" the timer interrupts with I/O interrupts. The order of the interrupts gets lost, the I/O interrupt is always delivered first. The timer interrupt comes in as soon as the interrupts get enabled again. This has a bad effect because most I/O interrupts trigger a bottom half which enables the interrupts. But ticks that arrive while the cpu is in a bottom half are system ticks and not user/idle ticks. So due to the change in the order of the interrupts the stochatic tick accounting gets wrong. blue skies, Martin
