Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

[Dan Hecht]

On 03/06/2007 04:24 PM, Jeremy Fitzhardinge wrote:
> Thomas Gleixner wrote:
> > > 3) clockevent set_next_event interface is suboptimal for paravirt (and 
> > > probably realtime-ish uses).  The problem is that the expiry is passed 
> > > as a relative time.  On paravirt, an arbitrary amount of (stolen) time 
> > > may have passed since the delta was computed and when the timer device 
> > > is programmed, causing that next interrupt to be too far out in the 
> > > future.  It seems a better interface for set_next_event would be to pass 
> > > the current time and the absolute expiry.  Actually, I sent email to 
> > > Thomas and Ingo about this (and some other clockevents/hrtimer feedback) 
> > > in July 2006, but never heard back.  Thoughts?
> > >     
> > There is no problem for realtime uses, as the reprogramming path is
> > running with local interrupts disabled. I can see the point for paravirt
> > and I'm not opposed to change / expand the interface for that. It might
> > be done by an extra clockevents feature flag, which requests absolute
> > time instead of relative time.
> >   
>
> I'm not sure how much different it makes overall.  It's true that
> absolute time would be a more useful interface, but because the guest
> vcpu can be preempted at any time, we could miss the timeout
> regardless.  In Xen if you set a timeout for the past you get an
> immediate interrupt; I presume the clockevent code can deal with that?

That's the problem though, you won't know to set it for the past since 
the expiry is relative.  When the vcpu starts running again, it will set 
the timer to expire X ns from now, not Xns from when the timer was 
requested.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/