Hi, Isaku Thank you for commenting this.
1)about new_itm value. "new_itm" is set from local_cpu_data->itm_next (later I use this as itm_next) at header part of timer_interrupt. So it does not effect itm_next changes in consider_steal_time(). 2)The difference of following time > > > ia64_get_itc() - (the itc of the last time > > > the timer interrupt handler was invoked) Every time should set next ITM like follows. local_cpu_data->itm_next(itm_next)+local_cpu_data->itm_delta(itm_delta). So "guessed last itc" should be itm_next - itm_delta This itm_delta effect is already considered on stolentick++; Thanks Atsushi SAKAI Isaku Yamahata <[EMAIL PROTECTED]> wrote: > On Fri, May 09, 2008 at 03:48:24PM +0900, Atsushi SAKAI wrote: > > > Isaku Yamahata <[EMAIL PROTECTED]> wrote: > > > > > > > > > do_div(stolentick, NS_PER_TICK); > > > > stolentick++; > > > > > > > > do_div(stolen, NS_PER_TICK); > > > > > > > > if (stolen > stolentick) > > > > stolen = stolentick; > > > > > > > > stolentick -= stolen; > > > > do_div(blocked, NS_PER_TICK); > > > > > > > > if (blocked > stolentick) > > > > blocked = stolentick; > > > > > > Could you please explain the above logic? > > > I guess that stolentick should be > > > ia64_get_itc() - (the itc of the last time > > > the timer interrupt handler was invoked) > > > or something like that. > > > > your suggested value is new_itm. > > That variable keeps as "local_cpu_data->itm_next" in the ia64 time code. > > No. local_cpu_data->itm_next doesn't hold such value because > the valuable is updated by consider_steal_time() so that the > wanted value is lost. > > -- > yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
