Hey, Christoph

While waiting for the arm-guys to bump the package, you may try this build:

https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3786788

Peter, do you know why the package hasn't been bumped for aarch64?

Ingvar

Hi Ingvar,

I just installed your RPMs and tested with them.
Works perfectly on my arm64 machine. :)

Thanks a lot,
Christoph

> Peter, do you know why the package hasn't been bumped for aarch64?

Because you didn't submit it as an update on primary (note the f25-updates-candidate tag) hence it won't mirror over until it's in testing.

https://koji.fedoraproject.org/koji/buildinfo?buildID=816783

And 4.4 is FTBFS in rawhide too btw https://koji.fedoraproject.org/koji/buildinfo?buildID=823900

> And 4.4 is FTBFS in rawhide too btw
> https://koji.fedoraproject.org/koji/buildinfo?buildID=823900

Yes, one of the tests fails on all but x86*. It's probably just a porting bug in the test, like size_t or something. I'm waiting for upstream. https://github.com/jemalloc/jemalloc/issues/526

Hi Ingvar,

this week I ran "dnf update" on my aarch64 server and jemalloc got updated to 4.4.0.
Thanks for that!

However, my original problem (I see a lot of warnings of the form
"munmap(): Invalid parameter" when running HHVM) still persist.

I was able to solve this problem by rebuilding using the following commands:

dnf download --source jemalloc
rpmbuild --rebuild jemalloc-4.4.0-2.fc25.src.rpm
sudo dnf reinstall ~/rpmbuild/RPMS/aarch64/{jemalloc-4.4.0-2.fc25.aarch64.rpm,jemalloc-debuginfo-4.4.0-2.fc25.aarch64.rpm,jemalloc-devel-4.4.0-2.fc25.aarch64.rpm}

Build log can be found here:
https://paste.fedoraproject.org/537774/

I compared the build log with the Fedora 25 build log from here:
https://arm.koji.fedoraproject.org/kojifiles/packages/jemalloc/4.4.0/2.fc25/data/logs/aarch64/build.log

The differences are as follows:

 * In my build log there is no "Patch #5 (jemalloc-4.4.0.disable_thp.patch)" patching
 * My pagesize is 4096 (Fedora build machine has 65536)
 * My kernel is 4.3 based (Fedora 25 build server uses 4.7)
 * My kernel supports transparent_hugepage as well
 * My jemalloc configure finds autoconf
 * My LG_PAGE is 12 (on Fedora build machine 16; see pagesize above)
 * My test/unit/pack.c compiles warning free

So I guess the different pagesize is the problem.

Other architectures support different pagesizes as well ([1]),
but have a default of 4k in Fedora 25 (at least on amd64, x86).
This leads to the following question:
Why is jemalloc for aarch64 compiled on a system with a pagesize of 64k?

I can give it a try to change my kernel config to use a 64k pagesizes
as well (should not make a difference on my 16 GiB machine), but other
arm64 machines with less RAM (e.g. Pine64/Raspberry Pi3) might not want
to use such a big pagesize (and thus cannot use jemalloc if they run
Fedora 25).

Thanks,
Christoph

[1] https://wiki.debian.org/ArchitectureSpecificsMemo

Hello Christoph

The patch jemalloc-4.4.0.disable_thp.patch is only applied if the kernel on the system you build the package, do not support transparent hugepages.

I have no actual fix for this. The pagesize on all fedora kernels on the same platform should be the same, should it not? If it isn't, how can we configure memory allocators?

I don't think jemalloc can reconfigure the page size at run time, but I can check.

Peter, do you have any comments?

Ingvar

Hi Ingvar,

over the weekend I've had a look at the default pagesize on several aarch64
Linux distributions. It seems like only Fedora has a pagesize which is not 4k.
Which is not a problem, if the Fedora kernel (and its config) is used.
As I cannot use the Fedora kernel (some drivers for my machine are missing),
it is my responsibility to provide one, which is compatible to the one from Fedora.
In short: after recompiling my kernel with a pagesize of 64k, jemalloc
works fine on my machine.

Dynamically detecting the pagesize would lead to slower code being generated by gcc
as the 4k/64k constant fits perfectly fine into a load-immediate instruction
whereas a dynamic lookup would have to load the value from memory (and it might
not be cached). This is something I would not like to see either... ;)

So feel free to close this ticket and thank's for all your help!

BR
Christoph