Xen devel - Sep 2006 - [Xen-ia64-devel] RE: IPF/Xen VTI domain testing report for Xen 3.0.3 RC1

>5. LTP testing might run very slow in SMP VTI Domain with credit scheduler.
If binding VTI
>and Xen0 vcpu, this bug won''t be there.
Hi keir,

In credit scheduler, two vcpus in the same domain may be scheduled on the same
CPU. For instance, vcpu0 and vcpu1 are running on the same CPU, vcpu0 is doing
spin_lock in guest, then time slice is due, vcpu0 is scheduled out before doing
spin_unlock, vcpu1 is scheduled in, vcpu1 is also trying to get the same spin
lock, yes vcpu1 can''t get this lock due to this lock has been got by
vcpu0, so vcpu1 tight loop until its time slice is due, so this domain is very
slow.
Of cause, even vcpu0 and vcpu1 are running on different CPUs, there is still
similar situation, but the impact is less.

What do you think about this?

Thanks,
Anthony



>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of You, Yongkang
>Sent: 2006年9月29日 21:16
>To: xen-ia64-devel@lists.xensource.com; xen-devel@lists.xensource.com
>Subject: [Xen-devel] IPF/Xen VTI domain testing report for Xen 3.0.3 RC1
>
>Hi all,
>
>We have tested IPF/Xen on 3.0.3rc1. The testing mainly focus on the VTI
domains. It
>includes guest booting, memory size, vcpu number, guest installation, SMP
guest, guest
>coexist, xm command, Xwindows and Windows 2k3. The testing results are good.
>
>There are only 6 issues found. All of them are not new.
>1. VTI domain and XenU domain might meet “Can not allocate memory”. This is
bug.
>http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=736
>
>2. Two xenU coexist testing might fail. This is bug
>http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=747
>
>3. VTI FC6-test2 installation failed. RHEL4u3 installation testing is pass.
>
>4. VTI multi NICs (>1) testing failed. Can only bring up 1 NIC in VTI
domain.
>
>5. LTP testing might run very slow in SMP VTI Domain with credit scheduler.
If binding VTI
>and Xen0 vcpu, this bug won''t be there.
>
>6. Xen0 couldn''t boot up with >=3G memory.
>
>=============>Detail Info:
>Hardware environment:
>Platform: Tiger4
>Processor: Itanium 2 Processor
>Logic Processors number: 8,16 (2,4 processors with Due Core)
>PAL version: 8.15
>
>IA64-Nightly testing cases:
>        Two_VTI_Coexist        pass
>        VTI_Without_vif          pass
>        One_VTI                pass
>        One_XenU              pass
>        VTI_LTP                pass
>        VTI_and_XenU           pass
>        Two_XenU_Coexist    __fail__
>        One_VTI_4096M         pass
>        VTI_Network             pass
>        XenU_Network           pass
>        One_SMP_XenU         pass
>        One_SMP_VTI           pass
>        VTI_Kernel_Build         pass
>        Four_VTI_Coexist        pass
>        VTI_Windows            pass
>        Windows_VTI_xenU_Co  __fail__
>
>VTI domain Memory size testing:
>        256M                   pass
>        512M                   pass
>        1G                     pass
>        2G                     pass
>        3G                     pass
>        4G                     pass
>        5G                     pass
>
>VTI domain vcpus testing:
>        2                         pass
>        3                         pass
>        4                         pass
>        5                         pass
>        10                        pass
>        11                        pass
>        12                        pass
>        16                        pass
>        17                        pass
>
>SMP_VTI functional testing:
>        LTP                     __fail__
>        Kernel-build               pass
>
>VTI Installation testing:
>        RHEL4U3                pass
>        FC6-test2               __fail__
>        Windows 2k3             pass
>
>Guest coexist:
>        2 VTI Win2k3 coexist      pass
>        8 VTI Linux coexist        pass
>        4 xenU coexist           __fail__
>
>Xen0 test:
>        Max_dom0_vcpus=2      pass
>        Max_dom0_mem=3072M __fail__
>
>Xwindows test:
>        RHEL4U2 Xwindows      pass
>        Mouse in Xwindows       pass
>
>Xm command:
>        xm list                   pass
>        xm info                  pass
>        xm destroy               pass
>        xm create                pass
>        xm dmesg               pass
>        xm vcpu-list              pass
>        xm vcpu-pin              pass
>        xend start                pass
>        xend stop                pass
>        xend restart              pass
>
>Other tests:
>        VTI Win2k3 app           pass
>        VTI with 4 IDE disks       pass
>        VTI with 4 NICs          __fail__
>
>Best Regards,
>Yongkang (Kangkang) 永康
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

On 29/9/06 14:28, "Xu, Anthony" <anthony.xu@intel.com> wrote:
>> 5. LTP testing might run very slow in SMP VTI Domain with credit
scheduler.
>> If binding VTI
>> and Xen0 vcpu, this bug won''t be there.
> 
> Hi keir,
> 
> In credit scheduler, two vcpus in the same domain may be scheduled on the
same
> CPU. For instance, vcpu0 and vcpu1 are running on the same CPU, vcpu0 is
doing
> spin_lock in guest, then time slice is due, vcpu0 is scheduled out before
> doing spin_unlock, vcpu1 is scheduled in, vcpu1 is also trying to get the
same
> spin lock, yes vcpu1 can''t get this lock due to this lock has been
got by
> vcpu0, so vcpu1 tight loop until its time slice is due, so this domain is
very
> slow.
> Of cause, even vcpu0 and vcpu1 are running on different CPUs, there is
still
> similar situation, but the impact is less.
> 
> What do you think about this?
IBM did some tests at one point which concluded that we''d get little or
no
benefit from paravirtualising spinlocks to yield-on-spin. This is mainly
because spinlock critical regions are usually very small. The chances of
preempting someone while they are in a spinlock critical region, *and*
scheduling someone else who wants to take the same lock, *and* not having
another CPU idle enough to run the lock-holding VCPU, should be very small.

 -- Keir



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel