Am 31.05.2011 um 21:49 schrieb Anthony Liguori:
On 05/31/2011 11:16 AM, Alexander Graf wrote:
On 31.05.2011, at 17:48, Anthony Liguori wrote:
On 05/31/2011 10:44 AM, Alexander Graf wrote:
On 31.05.2011, at 16:54, Jan Kiszka wrote:
On 2011-05-31 16:26, Anthony Liguori wrote:
Is there any reason we still carry multiple timer
implementations these
days?
HPET shouldn't be any better than dynticks.
On any recent kernel, for sure. BTW, the same applies to the RTC
timer.
So the obvious change would be to introduce CONFIG_HPET, ifdef
the SIGIO handling on that and also ifdef the host hpet handling
code on it? That way it's documented well and can preferably even
be turned off with --disable-host-hpet during configure time,
which we can then slowly turn to the default.
Or just remove hpet and rtc.
Does anyone really object to that?
--verbose please: We're not talking about "removal" of emulation of
such acronyms for i386 guests, but about ceasing to use some Linux-
only host facilities, right?
Do RHEL5 and SLES10 support dynticks? If yes, no objections.
They're the oldest really supported distros we should possibly
remotely even care about.
Yes, they do. But it's not as accurate as RTC/HPET because there is
no CONFIG_HRTIMERS.
But the problem with RTC/HPET is that there is only one /dev/rtc and
one /dev/hpet so only one guest can use it at any given time. It's
really not a generally useful solution.
At one point in time, it was the only way to get a high res clock.
Now, it Just Works provided you don't have an ancient kernel.
I'm curious, what's ancient these days? 2.6.29 or more like 2.4.x?
Andreas
