On Thu, Aug 04, 2011 at 10:42:45AM +0800, Wayne Xia wrote:
于 2011-8-4 7:48, Kevin O'Connor 写道:
On Wed, Aug 03, 2011 at 02:42:15PM +0200, Bjørn Mork wrote:
But what if additional data is added to the table, making f-segment allocation fail? Then you will end up with three different results depending on small changes instead of two:
- nCPU<= 16 and f-segment allocation OK: SMBIOS in f-segment
- nCPU> 16: SMBIOS in high mem
- nCPU<= 16 and f-segment allocation failed: no SMBIOS table
If a reasonable limit is placed on the size of the SMBIOS table then in practice the allocation will always succeed.
All of the f-segment allocations with the exception of the mptable are small. The mptable allocation should probably have an upper bound placed on it as well. There's currently 2048 bytes reserved for malloc_fseg (CONFIG_MAX_BIOSTABLE), and the current smbios uses 263 bytes with one cpu and 938 bytes with 16 cpus (memory size may also change size slightly).
In which situation would we allocate more that 16 VCPUS in qemu for 1 VM? I remember the performance is not very good when the number of virtual CPU is more than the real number of host's, So could we just put a limit about it, for a simple solution?
Limit the total number of CPUs? No - it's useful to be able to simulate many cpus. As before, we can limit the situations where smbios is put into low mem though.
-Kevin