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

[Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>]

Kevin,

Let me just try to use the deferrable timers as they are
specified today. If I have trouble doing so, then we can discuss
at that point.

thanks,
Dave

Tian, Kevin wrote:

>>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