于 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:
1) nCPU<= 16 and f-segment allocation OK: SMBIOS in f-segment
2) nCPU> 16: SMBIOS in high mem
3) 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).
-Kevin
_______________________________________________
SeaBIOS mailing list
[email protected]
http://www.seabios.org/mailman/listinfo/seabios
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?
--
Best Regards
Wayne Xia
mail:[email protected]
tel:86-010-82450803
_______________________________________________
SeaBIOS mailing list
[email protected]
http://www.seabios.org/mailman/listinfo/seabios
