Bug 496354 - Timer expires in a different rate depending on CONFIG_HZ
Timer expires in a different rate depending on CONFIG_HZ
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.3
i386 Linux
low Severity medium
: rc
: ---
Assigned To: Xen Maintainance List
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-17 21:00 EDT by kerdosa
Modified: 2009-04-17 21:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-17 21:32:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kerdosa 2009-04-17 21:00:21 EDT
Description of problem:
Timer expires in a different rate depending on CONFIG_HZ.

Version-Release number of selected component (if applicable):
RHEL 5.3 XEN

How reproducible:
Below

Steps to Reproduce:
1. Build two different kernels, one with 100HZ and the other is 1000HZ.
2. Install it to guest kernel on XEN.
3. Run a simple test program using nanosleep. 

Actual results:
The kernel built with 1000 HZ wakes up faster than the kernel built with 100HZ.

Expected results:
Regardless HZ config, it should expires at the same rate.

Additional info:
Thisis RHEL kernel-xen does not set XEN periodic timer which is 100HZ by default. When kernel is configured other than 100HZ, then kernel initialization code should set periodic_period by using VCPUOP_set_periodic_timer op.
Comment 1 Rik van Riel 2009-04-17 21:32:20 EDT
This is expected due to the way the timer infrastructure works in the RHEL 5 kernel. The non-xen kernel should show the same behaviour.

Current upstream and Fedora use a tickless kernel, which will behave like you expect things to work. Backporting those changes would be way too invasive and risky for a RHEL 5 update.

Note You need to log in before you can comment on or make changes to this bug.