>> E.g., on powerpc that's 16MB so they have *a lot* of memory blocks.
>> That's why that's not papering over the problem. Increasing the memory
>> block size isn't always the answer.
>
> Ok. If you don't mind, what's the purpose of hotplugging at that granularity?
> I'm simply curious.
On bare metal: none with that big machines AFAIKS. :)
For VMs/partitions it gives you much more flexibility ("cloud", kata
containers, memory overcommit, ...).
Assume you have a VM with some initial memory size (e.g., 32GB). By
hotplugging up to 256 DIMMs you cab grow in small steps (e.g., 128MB, up
to 64GB, 256MB, up to 96GB, ...). And if you online all the memory
blocks MOVABLE, you can shrink in these small steps.
Regarding PowerPC, AFAIK it also gives the OS more flexibility to find
memory blocks that can be offlined and unplugged, especially without the
MOVABLE zone. Finding some scattered 16MB blocks that can be offlined is
easier than finding one bigger (e.g., 2GB) memory block that can be
offlined. And the history of powerpc dlpar dates back to pre-MOVABLE
days (there is a paper from 2003).
>
>>> Yeah, but of course it's not as bad as it was now that it's fully parallelized.
>>
>> Right. I also observed that computing if a zone is contiguous can be
>> expensive.
>
> That's right, I remember that. It's on my list :)
I do think your change mostly affects bare metal where you do not care
about hotplugging small memory blocks. Maybe an even better check would be
if (!in_vm() {
bz = MAX_BLOCK_SIZE;
goto none;
}
because I doubt we have bare metal machines > 64 where we want to
hot(un)plug DIMMs < 2G. But maybe there is a use case I am not aware of
... and I don't know an easy way to check whether we are running inside
a VM or not (like kvm_para_available() ... ).
--
Thanks,
David / dhildenb
