On 18/09/2020 14:34, Neal Gompa wrote: > On Fri, Sep 18, 2020 at 8:19 AM Daniel Pocock <daniel@xxxxxxxxxx> wrote: >> >> >> >> On 16/09/2020 21:29, Josef Bacik wrote: >>> On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote: >>>> On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote: >>>>> At the time we tied the fs blocksize to the >>>>> page size, because it was unlikely that a user would mkfs a fs on one >>>>> arch >>>>> and move it over to another arch. >>>> >>>> But one doesn't need "another arch" for page size to change; many >>>> architectures (arm, mips, powerpc, sparc, to name a few) support multiple >>>> page sizes. >>> >>> Sure, but again you are not likely to change page size for an existing >>> system. The decision early on was to forgo this particular ability for >>> simplicity, and then we would revisit the decision later on. It's been >>> a while and there's still not been enough demand to justify the work >>> until recently. Thanks, >> >> >> This is messy but important >> >> Is it possible for Fedora to offer two flavours of the kernel package, >> like Debian? There, I created a -4k flavour so it builds two kernel >> packages, one with 4k and the other with 64k. They can both be >> installed on the same machine and one or the other selected in the grub >> menu on each boot. Either can mount an ext4 root but obviously they >> can't share the same btrfs root, only the one that created it can mount >> that root. >> >> Once an alternative kernel is available, people need an installer/rescue >> ISO including that kernel. This may mean making both permutations >> available as different installer ISOs, or including two kernels in the >> same ppc64el >> >> Installer logic: If somebody is using ANY non-4k page size, on any >> architecture, it would be useful to display a pop-up window with a >> warning about btrfs before they create their root filesystem. This will >> save a lot of trouble for people. They might not realize there is a >> problem until they've been using the system for a few days and then they >> have to reinstall it again. >> >> Finally, if both page sizes are available, it is desirable to do a build >> of every package for every page size. Some packages appear to sense the >> page size at compile time and assume it will always be the same at >> runtime. This is unfortunate. Maybe reproducible builds techniques can >> be used to build each package on two different page sizes, detect if the >> binary differs and if so, suggest checking for hard-coded page size. >> > > I think all of this effort required is why we probably *won't* do that. > > I would be interested in seeing what kind of performance differences > there are between 4K page sizes and 64K page sizes, but I don't > particularly want to make ppc64le change back to 4K page sizes, simply > because there's not much point to it. POWER systems are still largely > unavailable to people and that's not going to change anytime soon. It looks like a lot of packages are impacted by this issue, it is not just btrfs Examples that I already experienced personally: - Firefox, especially things involving media content, like WebRTC - Nouveau Both of those were fixed without any recompiling, just using the same Firefox and Nouveau binaries on a 4k kernel. > As for a warning, I do not have the cycles to do that. As it stands, > if I'm going to put my limited contributing energy into something, > it'd probably be to help upstream fix the problem with non-4K page > sizes in the first place. Since you're interested in this problem, > perhaps you could help upstream with testing the patches and writing > code to fix this? Especially since it sounds like you have hardware > and use-cases to test this with. In the 10 years since the 64k page size was selected, a lot of things still haven't been patched. People who buy these workstations don't necessarily have the bandwidth to fix all that. It feels like we're being pushed to fix stuff like that in other people's code when we could just use a 4k page size and not worry about it. It is a chicken-and-egg problem: people might be deterred from using the platform if they keep hearing reports that Firefox doesn't work. From my experience, Firefox is working and it is working better with the 4k page size kernel that I compiled. It looks like interest in the platform will increase too: FSF recently certified it as Respects Your Freedom. Vikings[1], in Germany, are making plans to distribute it in Europe. Overall, the machines are very nice for developers. Given the amount of parallelism in the architecture, a small development or support team could share one of these machines between 2 to 4 people in a multi-seat configuration. Regards, Daniel 1. https://vikings.net _______________________________________________ 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
