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