I'm running a squeeze DomU on xen 4.0.1 which is completely unloaded. I notice a difference in cpu states between iostat and top like:
top (in every iter):
Cpu0 : 0.2%us, 2.0%sy, 0.0%ni, 94.2%id, 2.7%wa, 0.0%hi, 0.0%si, 0.9%st
iostat -x 3 (first iter):
avg-cpu: %user %nice %system %iowait %steal %idle
0.19 0.00 1.98 2.69 0.88 94.26
iostat -x 3 (subsequent iters):
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.00 0.00 0.00 100.00
Am I right if I assume that top is showing me the cumulated precentages rather than the diff between now and now-1 iteration? I know that top understands for cumulative mode but this is off for me and should only affect process display, not cpu state statistics.
Bug? Maybe Xen related?
Regards
Tim
Best Answer
top,vmstat(and other similar xstats you can use) get their information from/proc/statTry catting that virtual file, you'll see counters for the CPU as a whole, plus one line for each hardware thread and some other interrupt counters.The numbers you can see for the CPU are the numbers of kernel jiffies that have passed since the system booted in the various states.
Whereas the first iteration of
vmstatwill simply show you the relative percentages based on a single read of those counters (which, as you say is based on the cumulative counts), top will actually poll the counters twice within about 0.5 seconds before you see the initial display, so a (possibly slightly inaccurate) reading of the current ratios will be the first thing you see.To confirm, try running:
strace -e open top |grep "/proc/stat"and you'll see two quick reads of much of/proc/, followed by one subsequent read per tick. This is why you always get a short delay before top appears.To my knowledge the kernel has no registers that track deltas for immediate access by userspace programs. It does for load average, maintaining three rolling averages of the count of 'running' processes across different time intervals; but nothing similar for CPU utilisation.
So: not a bug, but by design.