Hi, 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?
Thanks, Atsushi SAKAI >>From: Atsushi SAKAI >>Subject: Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating >>aVTImakexen0 >>Thanks for your comments, >>I measured the DomVTI boot up time to EFI shell. >>(CS10559) >> >>time emulation >>22sec nothing >>22sec domU pal_halt_light (Anthony's idea) >>28sec domU/0 pal_halt_light >> >>If it emulates only domU, idle-domain is not working. >>Which solution is better? >> >Yes if only emulating domU, idle-domain is not scheduled, >But what Idle-domain do is to call ia64_pal_halt_light. >It looks like dom0 is calling ia64_pal_halt_light on behalf of idle-domain. > > >Thanks, >Anthony > > >>Thanks, >>Atsushi SAKAI >> >> >>>Sakai-san, >>>Another short term approach, >>>When emulating PAL_HALT_LIGHT >>>If(dom0) >>> Ia64_pal_halt_hight(); >>>Else //domU >>> do_block; >>> >>>Thanks, >>>anthony >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] >>>>[mailto:[EMAIL PROTECTED] On Behalf Of Atsushi >>>>SAKAI >>>>Sent: 2006?7?11? 21:46 >>>>To: Alex Williamson; Zhang, Xiantao >>>>Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com >>>>Subject: Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a >>>>VTImakexen0 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@lists.xensource.com >>>>>http://lists.xensource.com/xen-ia64-devel >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Xen-ia64-devel mailing list >>>>Xen-ia64-devel@lists.xensource.com >>>>http://lists.xensource.com/xen-ia64-devel >>> >> >> >> > _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
