Fedora 35 (was F-34): going to 4k page size? Help needed

[pocock]

Personally, I'm curious about the possibilities with 64k but I think the platform will get more momentum with 4k over the next 2-3 years.  Any way to offer both would be good.

Notice that:

a) 4k kernel needs to be in the installer ISO image, if you build a kernel with Copr, you need to build an installer image too

b) all packages need to be recompiled using the 4k kernel, although I suspect less than 1% of packages will be sensitive to page size, doing a full rebuild is the only way to be sure

If anybody can add details to the thread in Fedora devel that is the best place to discuss it now

[q66]

what? this makes no sense

you don't need to recompile *any* packages, since source code can't know the page size ahead of time

even if something hardcodes page size, a recompilation will not help you (not to mention that things compiled with a 64KiB page size constant will work on both 64k and 4k kernels)

[pocock]

There are a small number of packages that are sensitive like this

Some comments in this thread:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AAXJFZNIRXK2WRHZVYD3RUGQGZEYUH74/

and here

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775788#15

[q66]

i don't see how that's relevant

1) recompilation gives you the same binary regardless of the kernel you are running
2) therefore, if you have stuff sensitive to page size, you have to identify and patch the specific packages
3) again, things that assume 64k generally work on both 4k and 64k, so there is no problem, it's only a problem the other way around

[q66]

I see sharkcz is already involved in this conversation. I personally am not aware of anything that would break as a result (in fact, as you correctly point out, many things would suddenly "just work"). My only hesitancy is it would make 64K page kernels more of a pariah than they are already, sort of like another situation with big-endian, and there are performance reasons for 64K pages. Might this, perhaps, be a Workstation-only change and keep the performance benefits for Fedora Server?

i'd rather see 64k just go away

the traditional page size for powerpc is 4KiB, large default pages just have more drawbacks than benefits and i'd be surprised if you could find me a single benchmark where larger pages give you performance benefits that you can't also get by using hugepages (ideally with madvise) while retaining all the benefits of smaller pages in the general case

also https://yarchive.net/comp/linux/page_sizes.html

[pocock]

In some cases, I think the build script (e.g. a configure script or Makefile) might call a function like "getconf(PAGESIZE)" and it saves the result

This is not good behavior but I think there are some packages like this but not very many

[ClassicHasClass]

@pocock is right; I've seen such packages. It may come down to marking them outright or submitting patches for them to check at runtime.

I'm loathe to see 64K go away completely because there's a reason for its existence even though it's not relevant to many of us. More importantly, however, I guarantee IBM won't let it, because the big systems that pay the bills all use it, so whatever we can do to get it to coexist won't be fighting institutional inertia.

[pocock]

I think it is good to have both options too, I'm not anti-64k by any means

On the other hand, the reality is that most developers in the Linux world, developers of device drivers and GPU manufacturers are only testing their products on systems with a 4k page size.  If the developers at AMD and NVIDIA include some ppc64le hardware in their test routines before a release then they are unlikely to release code that completely fails, as is the case right now.

[tle]

Sticky situation. I like to enjoy a smooth experience with amdgpu but at the same time I want to keep all QEMU KVM guest hosts running. There is no guarantee that amdgpu would function correct with 4K pages btw, so whatever we are proposing are just workaround NOT the proper fix for the issue.

My only hope is Intel, if the DG2 driver could run perfectly on 64K, I would definitely ditch AMD.

[sharkcz]

Due a recent issue with 5.11 kernels breaking Polaris-based cards (like my WX4100) we have now a couple of fixes to the 64k support in the amdgpu driver. We are interested in feedback from other cards as well.

Please install 5.11 kernel from my scratch build - https://koji.fedoraproject.org/koji/taskinfo?taskID=64908758 and let us know. The 3 patches are submitted for inclusion in the next Fedora kernel builds via https://gitlab.com/cki-project/kernel-ark/-/merge_requests/991, until they reach mainline. They are in the AMD's drm-next tree.

[MPC7500]

This is my dmesg output. I can boot with this Kernel, but still get error messages. It seems my Navi card differs from others. Best Kernel with no issues is still 5.4.xx.

[MauryG5]

MPC sorry but have you also tried with a Kernel compiled with 4K pages? I haven't been able to see in the output if this 5.11 you have tried is using or if you see from this output if they are enabled ...

[sharkcz]

@MPC7500, thanks for testing, it's really a different backtrace.

[pocock]

Any work on this topic in Fedora has now been undermined by the politics that is gripping large free software organizations.  This initiative is completely frozen and I can't say when it would resume.

During the Fedora 35 release cycle, many Red Hat employees joined the attacks on Dr Richard Stallman.  I wrote a blog about the human rights issues involved in these online mobs and subsequently received a number of malicious communications that undermine my voluntary work as a Fedora developer.

I would not expect Raptor to be keen on taking sides in these issues, after all, they made a big effort to attain the FSF RYF certification but the OpenPOWER hardware is coming from Red Hat's parent, IBM.  On that basis, I won't say a lot more about this but I feel that people who invested in this platform have a right to know that politics is getting ahead of important development issues.

[ClassicHasClass]

Most unfortunate.