Re: [Qemu-devel] [PATCH] Use SIGIO with caution

[Andreas Färber]

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