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: > >> > >> 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). > 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 _______________________________________________ SeaBIOS mailing list [email protected] http://www.seabios.org/mailman/listinfo/seabios
