>Although from the earlier discussion it still isn't quite clear to me: >Why must the HPET RTC emulation need to fire the alarm every 16ms? Is that not >something that can be fixed?
This is hpet driver's behavior. Please check the following comment which is copied from the file hpet.c /* HPET in LegacyReplacement Mode eats up RTC interrupt line. When, HPET * is enabled, we support RTC interrupt functionality in software. * RTC has 3 kinds of interrupts: * 1) Update Interrupt - generate an interrupt, every sec, when RTC clock * is updated * 2) Alarm Interrupt - generate an interrupt at a specific time of day * 3) Periodic Interrupt - generate periodic interrupt, with frequencies * 2Hz-8192Hz (2Hz-64Hz for non-root user) (all freqs in powers of 2) * (1) and (2) above are implemented using polling at a frequency of * 64 Hz. The exact frequency is a tradeoff between accuracy and interrupt * overhead. (DEFAULT_RTC_INT_FREQ) * For (3), we use interrupts at 64Hz or user specified periodic * frequency, whichever is higher. */ The alarm interrupt have a frequency of 64Hz. This is a tradeoff between accuracy and interrupt overhead. So that, I think 16ms(1/64s) interrupt is expected unless we change the driver's design. However, changing the driver's behavior is a huge modification. This driver already exists for a long time (starting from commit id :1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 or ealier). So, I tend not to modify this driver's behavior. Thanks Lee, Zhuo-hao
