[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH]Check the values of MAX_VIRT_CPUS and NR_CPUSfor SMP


  • To: "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 21 Apr 2006 11:46:31 +0800
  • Delivery-date: Thu, 20 Apr 2006 20:47:23 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZk45D0fdY2neZATd+3FBSZmgprqAAENmrg
  • Thread-topic: [Xen-devel] [PATCH]Check the values of MAX_VIRT_CPUS and NR_CPUSfor SMP

Hi, Atsushi,
        I'm still not clear about the relationship between
MAX_VIRT_CPUS and NR_CPUS. Why do you need to add that 
check to force MAX_VIRT_CPUS>=NR_CPUS?

        Normally for each physical cpu existing in cpu_present_map 
(or limited by max_cpus), __cpu_up is called and then a 
corresponding idle_vcpu will be created on that cpu. Later when 
timer interrupt is enabled on that physical cpu, scheduler begin to 
work with idle vcpu already existing. So it's really strange to see you 
have a physical cpu with scheduler running however with idle_vcpu 
as null.

        Could you post more detail why MAX_VIRT_CPUS makes 
above weird thing happening? If MAX_VIRT_CPUS is the point, you 
may need find real cause from other places...

Thanks,
Kevin

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Atsushi
>SAKAI
>Sent: 2006年4月21日 9:32
>To: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: [Xen-devel] [PATCH]Check the values of MAX_VIRT_CPUS
>and NR_CPUSfor SMP
>
>Hi, All
>
>  This is a patch for checking # of CPUs consistency.
>This patch compares the values of MAX_VIRT_CPU and NR_CPUS.
>The object of this patch is to avoid boot error for SMP case.
>
>Reason for the need of this patch
>
>When we were testing SMP system, Boot sequence was failed
>in the case of using BVT scheduler.
>Each CPU assumed to have idle_vcpu in scheduler.
>But these two values inconsistency makes the cpus which is not
>assigned idle_vcpu.
>This case is occurred MAX_VIRT_CPUS is less than # of Real CPU.
>(for example MAX_VIRT_CPUS = 4 and Real CPU = 8
>4Real CPUs are not assigned to idle_vcpu)
>Currently, no check routine exists in scheduler for this problem.
>To solve this problem, I added check routine in xen/sched.h.
>
>
>
>Current situations
>
>This problem is currently solved in IA64 by CSET;9495 patch by
>expanding both CPUS value to 64.
>(Previously MAX_VIRT_CPUS = 8 and NR_CPUS = 4)
>
>#define MAX_VIRT_CPUS 64 in xen/include/public/arch-ia64.h
>and
>#define NR_CPUS       64 in xen/include/asm-ia64/config.h
>
>But the logical limit of the IA64 Max CPU is larger than 64.
>If someone change these values, some possibility make this error again.
>
>To avoid this problem, I believe this check code should be exists.
>
>Signed-off-by: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
>
>
>Atsushi SAKAI

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.