[External] : Re: [RFC PATCH v1 00/57] Boot-time page size selection for arm64
Joseph Salisbury
joseph.salisbury at oracle.com
Fri Oct 18 13:06:54 PDT 2024
On 10/18/24 15:27, David Hildenbrand wrote:
>
>>>> Hi Ryan,
>>>>
>>>> First off, this is excellent work! Your cover page was very detailed
>>>> and made the patch set easier to understand.
>>>>
>>>> Some questions/comments:
>>>>
>>>> Once a kernel is booted with a certain page size, could there be
>>>> issues
>>>> if it is booted later with a different page size? How about if
>>>> this is
>>>> done frequently?
>>>
>>> I think that is the reason why you are only given the option in RHEL
>>> to select the kernel (4K vs. 64K) to use at install time.
>>>
>>> Software can easily use a different data format for persistance based
>>> on the base page size. I would suspect DBs might be the usual suspects.
>>>
>>> One example is swap space I think, where the base page size used when
>>> formatting the device is used, and it cannot be used with a different
>>> page size unless reformatting it.
>>>
>>> So ... one has to be a bit careful ...
>>>
>> Yes, that is what I was thinking. Once a userspace process does an I/O
>> and if it is based on PAGE_SIZE things can go south. I think this is
>> not an issue with THP, so maybe it's possible with boot-time page
>> selection?
>
> THP is a different beast and has different semantics: the base page
> size doesn't change: the result of getpagesize() is unmodified
> ("transparent").
>
> One would have to emulate for a given user space process a different
> page size ... and Ryan can likely tell some stories about that.
>
> Not that I consider it reasonable to have dynamic page sizes in the
> kernel and then try emulating a different one for all user space.
This is probably a case of ensuring proper documentation from the
distro or application vendor.
Or maybe some type of "Safety gate" could be implemented outside of the
kernel. Some check for the prior use of different page sizes, in the
cases where it could cause problems.
More information about the linux-arm-kernel
mailing list