[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang
Hi Alex, Our QA team reported that xen0 would hang after creating VTi domain @CSet 10688-10694. Should we reverse the logic of vcpu_itr_d first ? Maybe we can find out the real bottleneck later.:) Thanks & Best Regards -Xiantao OTC,Intel Corporation > -----Original Message----- > From: Atsushi SAKAI [mailto:sakaia@xxxxxxxxxxxxxx] > Sent: 2006年7月11日 21:46 > To: Alex Williamson; Zhang, Xiantao > Cc: Isaku Yamahata; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake > xen0 hang > > Hi, Alex > > Sorry for late. > > I found your problem(boot time difference w/ PAL_HALT_LIGHT emulation patch) > occurred in SMP(credit). > But, it does not occurred in UP, SMP(bvt) and SMP(credit w/ affinity). > > I think the emulation of pal_halt_light for domU > does not good work for DomVTI boot up > under credit scheduling w/o affinity. > > And consider the Xiantao survey, > qemu make heavy I/O operations at the boot up. > > Consider the above two conditions, > I think credit scheduler algorithm does not consider > the block state.(caused by pal_halt_light emulation) > So I want to switch off the vcpu migration at heavy load > > > I planned as follows. > > 1)In the short term, > I want to avoid this problem by > HALT the PAL_HALT_LIGHT emulation while DomVTI boot up. > or > Lock VCPUs migrations while DomVTI boot up. > (when Credit scheduler runs) > > 2)In the long term, > I will make a patch to avoid this problem. > (Consider the heavy io w/ vcpu migration) > > N.B. > I checked under CS:10559.(original patch made) > > Thanks, > Atsushi SAKAI > > > > > > >On Tue, 2006-07-11 at 19:42 +0800, Zhang, Xiantao wrote: > >> Hi Alex, > >> Seems this issue was caused by Cset 10688. In vcpu_itr_d, the current > >> logic purges vhpt with cpu_flush_vhpt_range but it is very heavy to > >> xen0. When creating VTi domain @ early stage, IO operation is very > >> excessive, so qemu was scheduled out and in very frequently and this > >> logic was executed every time. In addition, cpu_flush_vhpt_range using > >> identity map to purge vhpt may cause more tlb miss due to no TR map. > >> If remove vcpu_flush_tlb_vhpt_range logic although it definitely > >> needed, seems VTi becomes healthy. Maybe potential bugs exist there.:) > > > > Thanks for investigating Xiantao. Isaku, any thoughts on how to > >regain VTI performance? Thanks, > > > > Alex > > > >-- > >Alex Williamson HP Open Source & Linux Org. > > > > > >_______________________________________________ > >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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |