> 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