> On 15/02/2021 19:47, Gary Buhrmaster wrote: > > On Mon, Feb 15, 2021 at 6:39 PM Dan Horák <dan@xxxxxxxx> wrote: > > > >> The open question still is whether we should try to keep 64k as default > >> as it would allow to find the remaining bugs and offer 4k kernel variant > >> (COPR for ppc64le should be coming back soon), similar for the > >> installer (a new remix/spin). After BTRFS removes the page size > >> dependency, switching the kernels shouldn't cause any issues for users. > > > > I think it may be instructive to look at the enabling IPv6 > > had on the entire ecosystem (and going to ipv6-first > > networking). Which definitely broke things (and there > > remain, in the greater world, lots of things still broken > > when IPv6 is enabled). However, if we still used ipv4-first > > networking even more would almost certainly still be > > broken, because no one would experience or report > > the issues with IPv6. > > > > If you agree that fixing the 64K bugs are important > > (and I personally think they are), you need to go > > 64K first to get the reports, and get the fixes. > > > The problem is that not all ppc64le bugs are related to page size Welcome to the world of non x86 architectures. > I was recently looking at ffmpeg issues[1] that happen on any page size, > that is now fixed and it also fixes issues in Blender. > > Going to 4k page size, we effectively drain the swamp to the half-water > mark. Some bugs will go away, other bugs will still be there. It doesn't drain the swap at all, it just changes the water from one to another. > The volume of workstation bugs is actually quite intimidating. Even for > somebody with a lot of experience, it takes away a certain amount of > energy. Some users and maybe even some developers will spend so much > time on hacks and workarounds that they have no time or energy left to > report the bugs, bisect them or even fix them. At least you don't have to deal with big endian bugs in there too, and a bunch of us that have been working on non x86 architectures for years have no doubt solved a number of the problems already. aarch64 had a mix of 4K (Fedora) and 64K (RHEL) and we've dealt with 100s of these already, of course that doesn't rule out POWER specific ones. > But I do agree that we can't avoid 64k indefinitely. If there is a way > to support both page sizes and run unit tests for all packages on both > that would be really useful. In addition to unit tests, it would be > useful to have a manual check on Firefox, Thunderbird, LibreOffice, etc > before each major release on 64k. No easily, apparently having something you can set via a kernel command line for this stuff isn't straight forward, I started asking for that functionality for pages sizes back in the early days of aarch64 and I'm still waiting. > 64k issues for ppc64le will also get more attention when other > architectures go 64k, then we won't have all the pressure on ppc64le > users. IPv6 was for every architecture so the effort was spread a lot > more widely. aarch64 also has 64K page sizes so it's already a shared problem, and I've dealt with and fixed more bug around that I care to remember but you're not the only one that's had to deal with it. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
