On 20.01.25 01:39, Zi Yan wrote:
On Sun Jan 19, 2025 at 6:55 PM EST, Barry Song wrote:
<snip>
However, with this workaround, we can't use transparent huge pages.
Is the CMA_MIN_ALIGNMENT_BYTES requirement alignment only to support huge pages?
No. CMA_MIN_ALIGNMENT_BYTES is limited by CMA_MIN_ALIGNMENT_PAGES, which
is equal to pageblock size. Enabling THP just bumps the pageblock size.
Currently, THP might be mTHP, which can have a significantly smaller
size than 32MB. For
example, on arm64 systems with a 16KiB page size, a 2MB CONT-PTE mTHP
is possible.
Additionally, mTHP relies on the CONFIG_TRANSPARENT_HUGEPAGE configuration.
I wonder if it's possible to enable CONFIG_TRANSPARENT_HUGEPAGE
without necessarily
using 32MiB THP. If we use other sizes, such as 64KiB, perhaps a large
pageblock size wouldn't
be necessary?
I think this should work by reducing MAX_PAGE_ORDER like Juan did for
the experiment. But MAX_PAGE_ORDER is a macro right now, Kconfig needs
to be changed and kernel needs to be recompiled. Not sure if it is OK
for Juan's use case.
IIRC, we set pageblock size == THP size because this is the granularity
we want to optimize defragmentation for. ("try keep pageblock
granularity of the same memory type: movable vs. unmovable")
However, the buddy already supports having different pagetypes for large
allocations.
So we could leave MAX_ORDER alone and try adjusting the pageblock size
in these setups. pageblock size is already variable on some
architectures IIRC.
We'd only have to check if all of the THP logic can deal with pageblock
size < THP size.
This issue is even more severe on arm64 with 64k (pageblock = 512MiB).
--
Cheers,
David / dhildenb
