CentOS - Apr 2008 - Good news for virtual EL-4.x boxes

Currently, if you are running CentOS-4.x on a Vmware box you end up
with time skew problems. The main fix has been using a set of
recompiled kernel that has a HZ that is more fitting with what Vmware
expects (eg 100 hz). The 4.7 kernels look like they will not need
this:

http://jons-thoughts.blogspot.com/2008/04/rhel-and-vmware-time-skew-problems.html

Well, I've gotten quite the number of questions over the last few days
about time skew problems in RHEL4 and VMWare, so figured that I would
write this.

In RHEL4.7, there will be a kernel feature that allows you to pass
'divider=' on the command line in grub. The number must be a divisor
of 1000, and the most common value is 10 (yielding an effective timer
interrupt rate of 100Hz). I'm expecting the 4.7 beta to become
available Real Soon Now(TM), though I have no information as to when
that will occur. In the meantime, this change is available as a hotfix
from Red Hat's Global Support Services.

What this does is take the kernel tick rate (which defaults to 1000Hz)
and divides it by the value of divider, to come up with an effective
interrupt rate. You can verify that this is working by:

Before making the change, use 'watch --interval=1 cat
/proc/interrupts' and you'll notice that the timer interrupt is
incrementing by 1000 every second. After you make the change, you you
notice with the same command that it is incrementing via 1000/ every
second.

The vlaue of HZ that is exposed to modules is still 1000, thus not
breaking module ABI.

This same change is already present in RHEL5.1 today. In recent
Fedora's, this is unnecessary due to the advent of the tickless kernel
(which is useful for other reasons, including reduced power
consumption on laptops). It is likely that RHEL6 will also be based on
a tickless kernel.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

On Mon, Apr 21, 2008 at 8:27 AM, Stephen John Smoogen <smooge at
gmail.com> wrote:
> Currently, if you are running CentOS-4.x on a Vmware box you end up
>  with time skew problems. The main fix has been using a set of
>  recompiled kernel that has a HZ that is more fitting with what Vmware
>  expects (eg 100 hz). The 4.7 kernels look like they will not need
>  this:
>
> 
http://jons-thoughts.blogspot.com/2008/04/rhel-and-vmware-time-skew-problems.html
>
>  Well, I've gotten quite the number of questions over the last few days
>  about time skew problems in RHEL4 and VMWare, so figured that I would
>  write this.
>
>  In RHEL4.7, there will be a kernel feature that allows you to pass
>  'divider=' on the command line in grub. The number must be a
divisor
>  of 1000, and the most common value is 10 (yielding an effective timer
>  interrupt rate of 100Hz). I'm expecting the 4.7 beta to become
>  available Real Soon Now(TM), though I have no information as to when
>  that will occur. In the meantime, this change is available as a hotfix
>  from Red Hat's Global Support Services.
>
>  What this does is take the kernel tick rate (which defaults to 1000Hz)
>  and divides it by the value of divider, to come up with an effective
>  interrupt rate. You can verify that this is working by:
>
>  Before making the change, use 'watch --interval=1 cat
>  /proc/interrupts' and you'll notice that the timer interrupt is
>  incrementing by 1000 every second. After you make the change, you you
>  notice with the same command that it is incrementing via 1000/ every
>  second.
>
>  The vlaue of HZ that is exposed to modules is still 1000, thus not
>  breaking module ABI.
>
>  This same change is already present in RHEL5.1 today.
Just one word of caution here.  The current implementation of the
divider= option in RHEL5.1 has bugs
people might want to be aware of:

https://bugzilla.redhat.com/show_bug.cgi?id=315471

The kernel-vm packages offered by CentOS do not suffer from this
issue.  I hope the bugs get fixed soon in 5.1 and would not be present
in 4.7.

Akemi