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. 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. What are the thoughts of the Debian powerpc community? Regards. Cascardo.
Attachment:
signature.asc
Description: PGP signature