From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Winchell Subject: Re: [PATCH] Deferrable Timer Date: Tue, 22 Jul 2008 11:56:12 -0400 Message-ID: <4886031C.3020107@virtualiron.com> References: <1104166E0B63A341805FDB977862AAD201BC154A@pdsmsx414.ccr.corp.intel.com> <1104166E0B63A341805FDB977862AAD201BF479B@pdsmsx414.ccr.corp.intel.com> <487F53D1.6030104@virtualiron.com> <1104166E0B63A341805FDB977862AAD201BF4DE8@pdsmsx414.ccr.corp.intel.com> <4880B6D4.4020906@virtualiron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" Cc: Dave Winchell , xen-devel@lists.xensource.com, Keir Fraser , "Yu, Ke" , "Wei, Gang" List-Id: xen-devel@lists.xenproject.org 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@virtualiron.com]=20 >>Sent: 2008=C4=EA7=D4=C218=C8=D5 23:29 >> >>Vpt.c works in a similar fashion for its periodic timer. Other=20 >>clocksources, >>e.g. pit, rtc, are layred on vpt.c with interface=20 >>create_periodic_timer. >>I can imagine an option passed to create_periodic_timer signifying that >>a deferrable timer may be used. >> =20 >> > >Agree.=20 > > =20 > >>Ideally, the deferrable timer would have an option where a set=20 >>of allowable >>timeout values, rather than a range, could be provided. If it had this=20 >>option, we could keep >>the timeouts on the integer*period time line. Otherwise I need to warp=20 >>the comparator >>as discussed below. I anticipate that there may be some problems with >>warping. >> =20 >> > >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=20 >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. > =20 > > =20 > >>I realize that specifying a range gives you more options for combining=20 >>timeouts. >>I don't mind trying to solve the warping problem. >> =20 >> > >Yes, the purpose of the deferral is to reduce timer ticks, or else it >really make no sense. > > =20 > >>One further option would be a deferrable timer with a range=20 >>fallowed by=20 >>a non-deferrable >>timer to get back on the integer*period timeline for interrupt=20 >>delivery. >> =20 >> > >What's the purpose then? current algorithm to find whether one >timer should be deferred is to find whether other timers may=20 >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 > =20 >