[SLOF] [PATCH 2/2] Increase temporary buffer size of ibm, client-architecture-support call

Thomas Huth thuth at redhat.com
Tue Jan 12 20:26:32 AEDT 2016

On 23.12.2015 02:42, Alexey Kardashevskiy wrote:
> On 12/22/2015 07:25 AM, Thomas Huth wrote:
>> The buffer size that we currently use for the client-architecture-
>> support call currently only works if there is not more than 1 TiB
>> of hot-pluggable RAM for the guest. This will likely not be enough
>> in the near future, so increase the buffer size from 128 kiB to 2 MiB
>> instead. That should be enough to accomodate for 16 TiB of hot-pluggable
>> memory.
> Thanks, applied.
> Out of curiosity - how much of these 128KiB is actually used for this
> 1TiB of RAM? There are other bits too in that buffer and only a fraction
> of it is per that 1Tib and 2MiB of buffer will support more than 16TiB
> but how much more?

I think the biggest part of the buffer is used to store the
"ibm,dynamic-memory" property (see spapr_populate_drconf_memory() in the
QEMU sources). For each LMB, the code adds an entry with 6*4=24 bytes.
And if I've got the LMB stuff right, we've got an LMB for every 256 MiBs
of hotpluggable RAM, so for 1 TB there are 4096 LMBs. That means, for 1
TB of hotpluggable RAM, the "ibm,dynamic-memory" property already takes
24 * 4096 = 98304 bytes, and for 16 TB of hotpluggable RAM, that
property needs  1.5 MB of buffer space!

spapr_fixup_cpu_dt() seems to only add approx. 100 Bytes per CPU, so
assuming that we won't use more than 2048 CPUs very soon (the current
value from the kernel), this only contributes 200 kB of buffer space. So
the main culprit here is really the LMB stuff.


More information about the SLOF mailing list