[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Problems with enabling hypervisor C and P-statecontrol
>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] >Sent: Friday, October 24, 2008 4:31 PM >> >> Niraj, one more info here. From your log, cpus on your platform >> are actually indexed by: >> package 1 (0, 4, 8, 12) >> package 2 (1, 5, 9, 13) >> package 3 (2, 6, 10, 14) >> package 4 (3, 7, 11, 15) >> >> thus cpu0/1/2/3 actually indicates 1st core in each package, >> instead of 4 cores in 1st package. :-) > >We really ought to have code in Xen to make the enumeration consistent >regardless of the BIOS order. I don't really care whether its >sockets/cores/threads or threads/cores/sockets, but we really ought to >be consistent. If Xen wants to be consistent with one policy, as you suggested, it requires core/thread info known before booting APs, and then take that info in alloc_cpu_id. However core/thread info can be only acquired on AP by CPUID and sibling/core map can be constructed after all APs are booted. Then you may need a temporary cpu id allocated and then switch it to a real one later. This looks a bit messed on some arrays[NR_CPUS]. Is it worthy of doing that way, or just expose the mapping between xen cpu id and sockets/cores/ threads? Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |