Re: [RFC PATCH v1 57/57] arm64: Enable boot-time page size selection

Ryan Roberts
2024-10-16T08:34:10Z

On 15/10/2024 18:42, Zi Yan wrote:
> On 14 Oct 2024, at 6:59, Ryan Roberts wrote:
>
>> Introduce a new Kconfig, ARM64_BOOT_TIME_PAGE_SIZE, which can be
>> selected instead of a page size. When selected, the resulting kernel's
>> page size can be configured at boot via the command line.
>>
>> For now, boot-time page size kernels are limited to 48-bit VA, since
>> more work is required to support LPA2. Additionally MMAP_RND_BITS and
>> SECTION_SIZE_BITS are configured for the worst case (64K pages). Future
>> work could be implemented to be able to configure these at boot time for
>> optimial page size-specific values.
>>
>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>> ---
>
> <snip>
>
>>
>> @@ -1588,9 +1601,10 @@ config XEN
>> # 4K | 27 | 12 | 15 | 10 |
>> # 16K | 27 | 14 | 13 | 11 |
>> # 64K | 29 | 16 | 13 | 13 |
>> +# BOOT| 29 | 16 (max) | 13 | 13 |
>> config ARCH_FORCE_MAX_ORDER
>> int
>> - default "13" if ARM64_64K_PAGES
>> + default "13" if ARM64_64K_PAGES || ARM64_BOOT_TIME_PAGE_SIZE
>> default "11" if ARM64_16K_PAGES
>> default "10"
>> help
>
> So boot-time page size kernel always has the highest MAX_PAGE_ORDER, which
> means the section size increases for 4KB and 16KB page sizes. Any downside
> for this?

I guess there is some cost to the buddy when MAX_PAGE_ORDER is larger than it
needs to be - I expect you can explain those details much better than I can. I'm
just setting it to the worst case for now as it was the easiest solution for the
initial series.

>
> Is there any plan (not in this patchset) to support boot-time MAX_PAGE_ORDER
> to keep section size the same?

Yes absolutely. I should have documented MAX_PAGE_ORDER in the commit log along
with the comments for MMAP_RND_BITS and SECTION_SIZE_BITS - that was an
oversight and I'll fix it in the next version. I plan to look at making all 3
values boot-time configurable in future (although I have no idea at this point
how involved that will be).

Thanks,
Ryan

>
> Best Regards,
> Yan, Zi