tags 843926 fixed-upstream forwarded 843926 https://github.com/jemalloc/jemalloc/issues/467 tags 832931 - fixed-upstream forwarded 832931 https://jira.mariadb.org/browse/MDEV-11877 thanks
Sorry, sent to the wrong bug number. On 07/06/17 15:15, James Cowgill wrote: > Control: forwarded -1 https://github.com/jemalloc/jemalloc/issues/467 > Control: tags -1 fixed-upstream > > On 10/11/16 18:37, Thadeu Lima de Souza Cascardo wrote: >> clone -1 -2 >> reassign -2 libjemalloc1 >> retitle -2 jemalloc uses a hard coded page size detected during build >> bye >> >> >> So, I traced this to jemalloc using the incorrect page size during >> runtime. In fact, it detects the page size during build and set it up. >> This has a large potential for a mess. And what a mess! >> >> So, jemalloc in jessie has been built on a 4KiB-page system, and, this, >> has a hard-coded page size of 4KiB. While jemalloc in sid has a >> 64KiB-page size. When we try to build mariadb on jessie on a 4KiB-page >> size system, everything goes well. When we build it on partch, with a >> 64-bit 64KiB-page size kernel, things break, if it's a jessie jemalloc. >> >> Later upstream versions seem to support multiple page sizes during >> build. > > It looks like jemalloc 5.0.0 will support multiple page sizes > automatically as long as you pass the biggest possible page size when > you configure it: > https://github.com/jemalloc/jemalloc/pull/769 > > That patch is pretty big though, so it won't help with stretch. > >> For MariaDB specifically, one option would be to build it without >> jemalloc. Other users would still be likely affected, however. > > Limiting it to specific architectures is probably ok though. > > Thanks, > James
signature.asc
Description: OpenPGP digital signature
