[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] initialize some more cpuinfo fields
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 08.05.06 15:46 >>> > >On 8 May 2006, at 14:10, Jan Beulich wrote: > >> Namely preventing systems to look like single-socket ones with many >> cores (because all CPUs show physical ID being >> zero). > >Is it a problem to look like a many-core processor? Given that VCPUS >can get moved around between physical CPUs to load-balance, it doesn't >make much sense to take the physical IDs of CPUs that VCPUs happen to >run on when they boot. Yes, we have an irqbalance userland package that is, as I'm told, supposed to run only on multi-socket systems. >If the many-core appearance is a problem then we could synthesise >different physical IDs for VCPUs (probably by forcing physical ID to >VCPU number). This is what the patch does (it simply overrides whatever identify_cpu() provided). >The only exception to this 'lie' could perhaps be domain0 in some >situations, if we guarantee to run a dom0 VCPU on every physical CPU >and never change the pinning. Then calling identify_cpu() for each VCPU >makes sense, as does parsing SRAT data or otherwise obtaining NUMA info >via a Xen hypercall. Yes, if such a guarantee was made, then dom0 should behave like native (and should specifically also have/call set_cpu_sibling_map()), provided there are not currently any implications on cpu_sibling_map or cpu_core_map in the Xen specific code. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |