Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
On Fri, Jun 05, 2020 at 03:08:55PM +0200, John Paul Adrian Glaubitz wrote: > Is POWER5 still supported by the Linux kernel? I thought IBM removed a > bunch of older machines but kept PowerPC 970 support. 4.17 dropped power4. power5 and up are still supported just fine. -- Len Sorensen
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
On 6/5/20 3:03 PM, Lennart Sorensen wrote: >> Anyone with a large modern POWER machine is going to run the ppc64el >> port anyway. > > Only power8 and newer can run ppc64el, so all power 5, 6 and 7 users > would still need to run be. But there are probably a lot less than of > G5 users. And most people with work loads that have a use for 64k pages > are probably on newer machines too. Is POWER5 still supported by the Linux kernel? I thought IBM removed a bunch of older machines but kept PowerPC 970 support. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
On Fri, Jun 05, 2020 at 08:37:02AM +0200, John Paul Adrian Glaubitz wrote: > I would like to switch the ppc64 kernel back to 4k pages. The majority > of our users are people on G5 Macs anyway, so I don't see a point > in using 64k pages. > > Anyone with a large modern POWER machine is going to run the ppc64el > port anyway. Only power8 and newer can run ppc64el, so all power 5, 6 and 7 users would still need to run be. But there are probably a lot less than of G5 users. And most people with work loads that have a use for 64k pages are probably on newer machines too. -- Len Sorensen
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
On 5 June 2020, 11:21, Romain Dolbeau wrote: > On the subject of page size - 64 KiB makes a lot more sense than 4 KiB > when you have gigabytes of memory. The fact that x86-64 is stuck with > the page size of a 80386 with 4 MiB of RAM doesn't mean everyone > should be... And 64 KiB should gain traction on modern hardware, as > it's the default in e.g. RedHat for Arm64 (why RISC-V thinks 4 KiB is > OK for everyone I'll never understand, it's fine for small embedded > but not larger systems). I don't have the slightest of an idea what the different pagesize are good for. I would like to have a working operating system, and if the Nvidia driver nouveau doesn't work I don't have such a working operating system. Frankly, I don't care about the pagesize. I only had problems with switching between 4K and 64K and I would be glad if the Linux distribution for PPC and PPC64 would use the appropriate one for the hardware. Since most ppc64be systems are most likely Power Mac G5s, and half of those machines use Nvidia cards, this should be a heavy argument for using a compatible configuration. Anyway, I found this: https://yarchive.net/comp/linux/page_sizes.html I don't understand much, but Linus Torvalds seemed to think that 4K pages was a good idea. Just my 2¢...
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
Le ven. 5 juin 2020 à 09:41, Linux User #330250 a écrit : > Because: why not use btrfs on a 64-Bit PowerPC, right? Well, ZFS works fine on PPC64 (and PPC!) and 'someone' even contributed AltiVec acceleration for the RAID-Z algorithms :-) [in all fairness, I haven't tried ZFS Root on PPC64, only on x68-64 & SPARC64]. On the subject of page size - 64 KiB makes a lot more sense than 4 KiB when you have gigabytes of memory. The fact that x86-64 is stuck with the page size of a 80386 with 4 MiB of RAM doesn't mean everyone should be... And 64 KiB should gain traction on modern hardware, as it's the default in e.g. RedHat for Arm64 (why RISC-V thinks 4 KiB is OK for everyone I'll never understand, it's fine for small embedded but not larger systems). The PowerPC 970 only has 1024 entries in it's TLB IIRC, it's probably quite useful to be able to map 64 MiB instead of 4 MiB without TLB reloads... Broken software that can't work with non-4 KiB page size should be fixed rather than forcing everyone to stay on the 80's idea of memory usage. Most G5 owners probably maxed-out memory as it's dirt cheap nowadays (I know I have the full 16 GiB), and those CPUs need all the help they can get. That being said - I'm not the one doing the work and it's probably time-consuming to fix support for old hardware (which may or may not be even capable to deal with it in the first place), so if the only way to get proper support for old GPUs is to go back to 4 KiB page size, so be it. I'd appreciate it if we kept both variant rather than a full revert, though (if only for testing support isn't broken as it was for a while last year). Cordially, -- Romain Dolbeau
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
On 6/5/20 9:40 AM, Linux User #330250 wrote: > If someone was using btrfs, it might not work, at least I have hit this > issue back in 2016. Maybe they already fixed btrfs, but on my Power Mac > G5 with Nvidia GPU, I had to use a pagesize of 4k in order for nouveau > to work, but since I had created the btrfs partition before, it wouldn't > mount complaining about an unsupported sectorsize. I assume that happened because you created the filesystem while the kernel was running with 64k pages and btrfs used that to adjust the sectorsize. > No issue on ext4 filesystems, but still something to keep in mind. > Because: why not use btrfs on a 64-Bit PowerPC, right? I don't think switching back to 4k pages would prevent you from using btrfs, you will just have to recreate your filesystem. I also don't think we can cover each and every usecase. However, seeing the problems introduced by switching the page size, I'm surprised at all this change was made without any previous communication. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
Hello! On 5 June 2020, 08:37, John Paul Adrian Glaubitz wrote: > I would like to switch the ppc64 kernel back to 4k pages. The majority > of our users are people on G5 Macs anyway, so I don't see a point > in using 64k pages. If someone was using btrfs, it might not work, at least I have hit this issue back in 2016. Maybe they already fixed btrfs, but on my Power Mac G5 with Nvidia GPU, I had to use a pagesize of 4k in order for nouveau to work, but since I had created the btrfs partition before, it wouldn't mount complaining about an unsupported sectorsize. No issue on ext4 filesystems, but still something to keep in mind. Because: why not use btrfs on a 64-Bit PowerPC, right?
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
Hi Ben! > I'm sorry this is still unresolved. I have a couple of questions: > > * How will people discover this and know that they should use it? If > the installer is still being updated for ppc64, shouldn't we select > this kernel automatically when an Nvidia PCI device is detected? > > * Has anyone talked to the nouveau developers recently about either (a) > fixing support for larger pages or (b) fixing the dependencies for the > driver so it can't be built in an unsupported configuration? >From what I have read in the upstream bug tracker discussion, fixing this seems non-trivial as even the proprietary driver is using a hack to address this problem [1]. > In any case, if nouveau is completely broken with 64K pages then we > should make sure nouveau is disabled in our default ppc64 > configuration. I would like to switch the ppc64 kernel back to 4k pages. The majority of our users are people on G5 Macs anyway, so I don't see a point in using 64k pages. Anyone with a large modern POWER machine is going to run the ppc64el port anyway. Adrian > [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/258 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
