> HZ is used as a macro allover in the kernel, not a variable. I know, but it doesn't mean that it cannot be changed, or rather, that the original timing problem cannot be solved in a better way. I remember a lot more about the VM kernel than I have learned about the Linux kernel, but if you take a step back, it doesn't make a whole lot of sense to request 1,000 timer interrupts per second plus another 1,000 per CPU just to keep the time up to date. A 1U server can have a whopping 9,000 interrupts per second at idle just to keep the clock going, multiply that by let's say 10 guests (not a big number for 8 CPUs) and it is a nightmare. And it is purely opportunistic. Linux requests more timer interrupts if you have more CPUs not because keeping the time updated becomes a challenge with many CPUs but simply because it tries to get as many opportunities as possible to synch the time, and each additional CPU makes it possible to request more interrupts. The result is so erratic that, ironically, the time goes totally out of synch in a virtual machine. Even with just 4 CPUs on my main mail machine, I was pulling my hair out getting the time to stay within one minute of the real world so that I could make sense of "Received:" headers, until I zapped HZ to 100 and everything started working as it should. Even with the VMware tools installed and ntpd disabled, I could not get the time to work reliably and it was an embarrassment. The good news is that it has become a configuration option in 'make menuconfig' rather than a zap to the source code. But it is a surprisingly big problem for SMP Linux guests, at least in mail environments where time stamps matter. VMware works so well that it took me a long time to even suspect that I had not done something stupid :-) Eric