>> Essentially CONFIG_SPARSEMEM, whereby we can have huge holes in physical
>> memory layout and memory areas coming/going with memory hot(un)plug.
>> Usually we manage all metadata per section. For example, pageblocks are
>> allocated per section. We avoid arrays that depend on the
>> initial/maximum physical memory size.
CONFIG_SPRSEMEM has been opened in some of our product with
Qcom-platform and
MTK platform. AFAIK, multi_freearea would not bring problem to
it？because the patch
just manage the physical memory of zone to serveral section(free_area)
and adjust the
the range of pages-PFN for buddy-alloc-pages by the alloction-order.
With memory
hot(un)plug, we would initialize the members of "multi_freearea" in zone.
From your description only I cannot tell how that would really work.
Your description of 1) indicated that we are dealing with an array to
manage memory segments, and arrays are a bad data structure when it
comes to sparsity.
The patch has been merged in the baseline of our product that has been
sold all over the
world with Linux-4.4/4.9/4.19 so that i don't think there will be too
much risk. Of course,
i might be wrong.
Just always keep in mind that upstream Linux has a very broad community.
What might be "good enough" for smartphones might not be well suited for
servers, VMs, embedded devices, other archs ... just imagine the RAM
size differences, sparse layout, dynamic memory changes, ...
Adding additional complexity to the buddy has to have a compelling
benefit; keep in mind that any complexity we introduce has to be
maintained in the long term.
Having that said, starting with small steps is IMHO the right approach.
--
Thanks,
David / dhildenb
