This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH]Check the values of MAX_VIRT_CPUS and NR_CPUSfor SMP
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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...


>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Atsushi
>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
>#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