Re: Using 4KiB page size by default on buildds
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
> 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
> 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.
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)...
Thanks anyway for your interest in powerpc.
-M
Reply to: