RE: [Xen-devel] [PATCH] Deferrable Timer

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Dave Winchell [mailto:dwinchell@xxxxxxxxxxxxxxx] 
>Sent: 2008年7月18日 23:29
>
>Vpt.c works in a similar fashion for its periodic timer. Other 
>clocksources,
>e.g. pit, rtc, are layred on vpt.c with interface 
>create_periodic_timer.
>I can imagine an option passed to create_periodic_timer signifying that
>a deferrable timer may be used.

Agree. 

>
>Ideally, the deferrable timer would have an option where a set 
>of allowable
>timeout values, rather than a range, could be provided. If it had this 
>option, we could keep
>the timeouts on the integer*period time line. Otherwise I need to warp 
>the comparator
>as discussed below. I anticipate that there may be some problems with
>warping.

Not sure why this option is required. In any case, you just keep cmp
updated by integer*period which is just enough in timer fn and has 
nothing to do with whether timer is deferred. Timers are always deferred
before and after, with only difference on the extent, especially when
you consider the point when guest gets chance to act on it.

>
>I realize that specifying a range gives you more options for combining 
>timeouts.
>I don't mind trying to solve the warping problem.

Yes, the purpose of the deferral is to reduce timer ticks, or else it
really make no sense.

>
>One further option would be a deferrable timer with a range 
>fallowed by 
>a non-deferrable
>timer to get back on the integer*period timeline for interrupt 
>delivery.

What's the purpose then? current algorithm to find whether one
timer should be deferred is to find whether other timers may 
expire in its tolerated future, regardless of whether next timer
is deferrable or not. Why do you care whether next one is
non-deferrable?

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel