View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000073||Cloud||General||public||2022-04-08 17:55||2022-04-08 20:06|
|Reporter||Liam Hopkins||Assigned To||Mustafa Gezen|
|Summary||0000073: Rocky 8 images on Google Cloud Platform should disable 64k page size|
|Description||Enterprise Linux version 8 distributions experimentally moved to 64k pages, which was reverted in Enterprise Linux version 9 due to incompatibilities. Please modify the Rocky Linux 8 for GCP kernel build to disable 64k pages to match.|
|Tags||No tags attached.|
|thanks for quick reply. everything you said makes sense as a general EL derivative. i may have misfiled the bug, this is a request for a change to the google-specific rocky image being built by CIQ, which *does* have a custom kernel build.|
I would recommend that you reach out to CIQ directly as it is their kernel and thus their modifications. We do not have hands nor knowledge in what the company does or modifies away from the Rocky Linux base.
Hi all - I can clear up a bit here.
This is going to be a contribution via the Cloud SIG - my apologies for the miscommunication as I asked Liam to file the ticket here.
Taking this one for myself.
Thanks Neil, and sorry for the confusion Louis. This is indeed about the SIG/Cloud kernel to improve Rocky on cloud platforms even if it diverges from upstream.
After talking to Neil, I'll be re-assigning this to myself and take the lead regarding SIG/Cloud kernel improvements until the initial release.
Also thanks for filing a bug Liam, this shouldn't require too much work hopefully. I'll keep in touch!
Unfortunately we do not modify our kernels nor do we roll our own kernels.
From a Release Engineering standpoint, our kernels are to match what is upstream (RHEL) with only branding and secure boot changes. Red Hat has stated in their bugzilla (and other mediums) that reducing the page size back to 4K on RHEL 8 would introduce KABI incompatibility and breakage. This implies that backporting said change is not a supported option.
My recommendation would be to take the current kernel SRPM and test reducing the page size that way. If it does work, then it could be a potential addition/collaboration with SIG/kernel, but will unfortunately increase the amount of overhead in keeping all kernels in line and up to date as they come upstream. And as a result, can create various KABI incompatibilities with the rest of the distribution. But it will be up to you (and others) to test and confirm this to check if the pros outweigh the cons.
As an aside, this 64k page size started with various questions asking about Apple's M1 hardware (which is a limitation on their part). This (among other reasons such as drivers which do not work on non-standard page sizes) is why page sizes are being reduced for non-x86 architectures.