On Mon, Nov 14, 2016 at 09:17:56AM +0100, Mathieu Malaterre wrote: > Hi, > > On Sat, Nov 12, 2016 at 12:02 PM, Thadeu Lima de Souza Cascardo > <cascardo@debian.org> wrote: > > Hi, > > > > While recently investigating the mariadb bug, I found out the culprit is > > in fact jemalloc. This library assumes the system page size is the one > > that it found when building it. The version in Jessie was built on a > > 4KiB-page size system. So, when using it on a 64KiB-page size system, we > > might see crashes. That's why building mariadb for Jessie on partch > > fails. mariadb uses jemalloc and during make check, a crash induces a > > deadlock. > > Nice ! added usertags 'powerpc': > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=powerpc&user=debian-powerpc%40lists.debian.org Thanks. > > > To give some context, I used to work fixing drivers for IBM Power > > Systems, which used 64KiB-page size kernels on most situations. And we > > found many issues due to people assuming 4KiB page sizes. > > > > Even though we could debate about the value of using any page size > > different from 4KiB, the fact is that there are systems out there using > > different page sizes, and even Debian ships with some kernels and uses > > it on its buildds. > > > > I, for one, believe we should support such different page sizes on the > > entire archive. This means fixing jemalloc, device drivers, other memory > > allocators and any other software that might break or work suboptimally > > on such systems. > > > > However, the current state of things has meant that powerpc has been > > dropped from squeeze and while I would agree that jemalloc might have > > been an exception, who knows what else might break because of such > > differences? We might look for things like page.*size/i in the archive, > > but upstream fixes might not always be an easy and quick path. Consider > > the jemalloc case, where upstream has diverged a lot from the current > > version in Debian, and I am not sure how they might take a fix for the > > version in Jessie. > > > > So, my proposal here is that we decide on a default page size for > > buildds and kernels shipped with Debian, give the option for the > > different page size for other users, but state there might be breakages > > when using it. That doesn't mean it's not supported, and shipping it is > > a way of giving the chance for it to be tested. It's not broken either, > > most things should work, but some things here and there are broken, and > > we could even have a list of known issues (that we want to fix > > eventually, though in future releases). > > > > Given that most users I see on this list are using 10+ year old > > hardware, which likely have low memory capacity and some support only > > 32-bit kernels, I'd say we default to 4KiB page size, and that's where > > most software will work, while 64KiB page size will impact much more > > broken software. > > > > Next steps here are getting a 64-bit kernel built with 4KiB page size > > available in the archives, and using those kernels on those buildds that > > currently run a 64-bit kernel. > > The old ppc64 was this way, see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826796 > Yeah, when I talked about drivers, I was thinking about nouveau, as I have read before on this list that it was a problem on 64KiB page size kernels. > > What are the thoughts of the Debian powerpc community? > > As you know 'powerpc' has been removed from the release archs. So > instead I would suggest that you get in touch with reproducible people > instead. Ideally the autopkg test should (could?) be run on a kernel > with different page size. > Good point bringing up that the package would produce different binaries, hence the reproducible build folks might take an interest. But I don't think we should it *instead*. We should it *too*. powerpc has been removed from Stretch. It may be included in Stretch+1, or at least I would expect ports.d.o to pick it up. Does it make sense? > But I fail to see how you can address something like: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819711 > > The page size is hardcoded (at built time) to 64K, so that it passes > on both partch.d.o (64K page) as well as my old G4 (4K page)... You mean that it will produce the same binaries no matter the build system? But does it run fine on 4KiB page size systems? I agree scenarios where the software builds assuming a 64KiB page size because it's PPC will not be handled by my proposal. I still think such software is broken and must be fixed. But 4KiB as the default size should still show less broken software for the user. This particular bug seems to show exactly the kind of problem that we have because of different page sizes on kernels we use to build packages. A FTBFS was caused when it was built on partch on a 64KiB-page size kernel. Had we set the plan above in motion many months ago, perhaps we would have had a healthier powerpc port? Best scenario in my opinion would be that we still build packages on 64KiB page size kernels, but on a test setup, where we try to rebuild the entire archive and watch for failures. I will see if I can start some work on that, I will ask Breno for a VM at Unicamp. > > Thanks anyway for your interest in powerpc. > > -M Regards. Cascardo.
Attachment:
signature.asc
Description: PGP signature