>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
|
Home