WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating aVTImakexen0 h

Hi SAKAI.

You misunderstood. There are two issues.

- one issues is related to stop_timer()
  stop_timer() prevents the message.
  "Ooops, pending guest timer before its due"
  This isn't very serious.

- another issues is related to TIMER_SLOP.
  This issue is that non-VTi domain hangs. This isn't fixed by stop_timer().
  As Anthony pointed out, adding TIMER_SLOP isn't complete fix.
  This issue is serious.

It seems to take a while for you to fix them.
Then, please back out your change at first.

Thanks.

On Tue, Jul 18, 2006 at 10:56:53PM +0900, Atsushi SAKAI wrote:
> Hi, Anthony and Yamahata
> 
> Thank you for your comments. and sorry for late.
> I know Anthony modification(stop_timer) fix the problem in empirically. 
> But, I am investigating the reason.
> 
> The problem is two timer function exists after defining the hlt_timer_fn.
> Two timer function confliction exists within the  vcpu_timer_expired => 
> vcpu_pend_timer => DomU => vcpu_set_itm or hyper_set_itm
> Because domain_itm keeps old value until vcpu_set_itm or hyper_set_itm is 
> called.
> For this reason, it has possibility that another VIRQ_ITC interrupt can call 
> during this window.
> To fix this problem, it should exclude VIRQ_ITC interrupt duing that time 
> window.
> 
> 
> and this problem is reproduced by using lmbench.(Thanks)
> 
> 
> Thanks
> Atsushi SAKAI
> 
> 
> 
> >Hi, Yamahata,
> >
> >If this domain depends on hlt_timer to wake it up,
> >The scenario you described can appear,
> >TIMER_SLOP can reduce this situation, but can't eliminate this situation.
> >Maybe we need another mechanism to wake up VCPU, when this VCPU
> >has been blocked for a certain time.
> >
> >Thanks,
> >Anthony
> >
> >
> >
> >>From: Isaku Yamahata 
> >>Hi SAKAI.
> >>
> >>The Anthony's modification is required.
> >>Without the modification, all physical CPUs end up in the idle loop and
> >>can't get out of it in spite of runnable vcpus existance because
> >>of TIMER_SLOP. This issue isn't related to VT-i domain.
> >>
> >>Thanks.
> >>
> >>On Wed, Jul 12, 2006 at 10:30:47PM +0800, Xu, Anthony wrote:
> >>> Hi, SAKAI
> >>> Forget wrong analysis in early email,
> >>>
> >>> In the phase of EFI boot, there are many IO operations, so dom0 is woken 
> >>> up
> >>by
> >>> VTIdomain in most time, while hlt_timer is still registered, this may 
> >>> cause
> >>more
> >>> timer interrupts injected to dom0 than before.
> >>>
> >>> Hope following modification help
> >>> #define TIMER_SLOP (50*1000) /* ns */
> >>>       set_timer(&v->arch.hlt_timer,
> >>vcpu_get_next_timer_ns(v)+TIMER_SLOP );
> >>>       do_sched_op_compat(SCHEDOP_block, 0);
> >>>       stop_timer(&v->arch.hlt_timer);
> >>>
> >>> Thanks,
> >>> Anthony
> >>>
> >>>
> >>> >-----Original Message-----
> >>> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >>> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xu,
> >>Anthony
> >>> >Sent: 2006?7?12? 21:13
> >>> >To: Atsushi SAKAI; Alex Williamson; Zhang, Xiantao
> >>> >Cc: Isaku Yamahata; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >Subject: RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690,creating
> >>aVTImakexen0
> >>> >hang
> >>> >
> >>> >>From: Atsushi SAKAI
> >>> >>Sent: 2006?7?12? 19:05
> >>> >>My primary motivation is correct display of xenmon.py and xentop in
> >>BVT/CREDIT.
> >>> >>(N.B. SEDF displayed as same as x86, but BVT/CREDIT are not)
> >>> >>If only domU emulation is applied, it is a half way from my motivation.
> >>> >>Is dom0 dispatch another home work?
> >>> >>
> >>> >
> >>> >I suspect the slowness is not due to dom0 being scheduled out, but due to
> >>> >hlt_timer
> >>> >didn't work as expected.
> >>> >           set_timer(&v->arch.hlt_timer, vcpu_get_next_timer_ns(v));
> >>> >           do_sched_op_compat(SCHEDOP_block, 0);
> >>> >There is a time window between set_timer and dom0 being scheduled out, 
> >>> >and
> >>psr.i
> >>> >is 1. So if hlt_timer fires before do_sched_op_compat being called, dom0 
> >>> >will
> >>> >not be woken up by hlt_timer, and there is no timer interrupt for dom0 
> >>> >until
> >>> >domo
> >>> >is woken up ,yes, dom0 can be woken up by other external interrupts, but 
> >>> >not
> >>> >by
> >>> >timer interrupt. And since dom0 is involved in VTIdomain bootup, this may
> >>lead
> >>> >to slowness of VTIdomain bootup.
> >>> >
> >>> >Above is my analysis, there isn't any evidence.
> >>> >
> >>> >You can do experiment to check it.
> >>> >Change above code sequence as following, this may reduce the impact of 
> >>> >time
> >>> >window.
> >>> >
> >>> >set_timer(&v->arch.hlt_timer,
> >>> >cycle_to_ns(local_cpu_data->itm_delta)+NOW());
> >>> >do_sched_op_compat(SCHEDOP_block, 0);
> >>> >
> >>> >_______________________________________________
> >>> >Xen-ia64-devel mailing list
> >>> >Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> >http://lists.xensource.com/xen-ia64-devel
> >>>
> >>> _______________________________________________
> >>> Xen-ia64-devel mailing list
> >>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> http://lists.xensource.com/xen-ia64-devel
> >>
> >>--
> >>yamahata
> >
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel

-- 
yamahata

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