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