Set JEMALLOC_SYS_WITH_LG_PAGE=16 at build

[schredder]

Support large page sizes becoming more common on arm64 systems. This is compatible with systems that use smaller page sizes.

Related issue: #261

[QuantumEntangledAndy]

What arch's have you tested this with? Any idea if it can cause issues with the non arm64 builds?

[schredder]

What arch's have you tested this with? Any idea if it can cause issues with the non arm64 builds?

I haven't tested it on other arch's yet, though as far as I have read (this is also @jasoncodes impression on my issue), using a larger page size won't be a problem for kernels configured for smaller page sizes.

My custom build based on v0.6.3rc1 runs on my pi5, but it kept throwing 401's at Scrypted when it was trying to start an rtsp stream, so I switched back to v0.6.1 last night. I'll have to keep playing with it, maybe set v0.6.3rc1 up on a different amd64 host and see if I can repro that error. (unless that's something you happen to be aware of?)

[jasoncodes]

FYI I pulled the arm64 build artifact for this PR and can confirm that the new build works on my machine when I mount the binary into the latest available container image.

---

Since all other supported architectures (i386, amd64, and armv7) use 4k pages, it may make sense to only set this on arm64 but I don’t think it matters much. As mentioned above, it’ll will work fine with a jemalloc page size larger than the kernel page size. Maybe it’ll use a little bit more memory or run slightly slower? The difference may not even be noticeable but it’d take benchmarking to confirm.

Note that JEMALLOC_SYS_WITH_LG_PAGE=16 looks to be 64k pages (2**16) not 16k pages (2**14). We only need 16k for Apple Silicon and Raspberry Pi 5 but, as above, 64k should be totally fine (and is future-proof as arm64 can be 64k too).

[QuantumEntangledAndy]

Ok then let's merge it