[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating aVTImakexen0 hang
- To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
- From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
- Date: Tue, 18 Jul 2006 15:27:03 +0800
- Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 18 Jul 2006 00:27:55 -0700
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
- Thread-index: AcaqOk79ZX39DGdcRiSdL7bI1IJ+HAAAHdYg
- Thread-topic: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating aVTImakexen0 hang
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.
>From: Isaku Yamahata
>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.
>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
>> VTIdomain in most time, while hlt_timer is still registered, this may cause
>> timer interrupts injected to dom0 than before.
>> Hope following modification help
>> #define TIMER_SLOP (50*1000) /* ns */
>> do_sched_op_compat(SCHEDOP_block, 0);
>> >-----Original Message-----
>> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xu,
>> >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
>> >>From: Atsushi SAKAI
>> >>Sent: 2006?7?12? 19:05
>> >>My primary motivation is correct display of xenmon.py and xentop in
>> >>(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
>> >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
>> >is 1. So if hlt_timer fires before do_sched_op_compat being called, dom0
>> >not be woken up by hlt_timer, and there is no timer interrupt for dom0 until
>> >is woken up ,yes, dom0 can be woken up by other external interrupts, but not
>> >timer interrupt. And since dom0 is involved in VTIdomain bootup, this may
>> >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
>> >do_sched_op_compat(SCHEDOP_block, 0);
>> >Xen-ia64-devel mailing list
>> Xen-ia64-devel mailing list
Xen-ia64-devel mailing list