On Wed, Mar 01, 2023 at 08:39:08AM +0100, Otto Moerbeek wrote: > On Wed, Mar 01, 2023 at 08:31:47AM +0100, Theo Buehler wrote: > > > On Tue, Feb 28, 2023 at 05:52:28PM +0100, Otto Moerbeek wrote: > > > Second iteration. > > > > > > Gain back performance by allocation chunk_info pages in a bundle, and > > > use less buckets is !malloc option S. The chunk sizes used are 16, 32, > > > 48, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384, 448, 512, 640, > > > 768, 896, 1024, 1280, 1536, 1792, 2048 (and a few more for sparc84 > > > with it's 8k sized pages and loongson with it's 16k pages). > > > > > > If malloc option S (or rather cache size 0) is used we use strict > > > multiple of 16 buckets, to get as many buckets as possible. > > > > > > See the find_bucket() and bin_of() functions. Thanks to Tony Finch for > > > pointing me to code to compute nice bucket sizes. > > > > > > I think this is ready for review and wide testing. > > > > Two vala-based ports, graphics/birdfont and productivity/minder, run out > > of memory when attempting to build them with this diff (and its previous > > version) on both amd64 and arm64: > > > > ***MEMORY-ERROR***: valac[93681]: GSlice: failed to allocate 2032 bytes > > (alignment: 2048): Cannot allocate memory > > Thanks, this smells like a bug in the aligned mem case. > > + pof2 = 1 << MALLOC_MINSIZE; > > should be > > + pof2 = MALLOC_MINSIZE; > > By the looks of it. I'll get back to this.
I can confirm that changing this fixes this issue with both ports on amd64 and arm64. > > -Otto > > > > > Abort trap (core dumped) > > > > To be able to build birdfont with PORTS_PRIVSEP = Yes, I had to bump > > _pbuild's datasize-cur to 15G, while 14G was not enough. That's nearly > > double the current default. On amd64 without this diff, birdfont builds > > comfortably with a datasize-cur of 1G. > > > > birdfont may be easier to investigate since the error happens early in > > the build. You can get there relatively quickly by doing > > > > cd /usr/ports/graphics/birdfont > > doas pkg_add birdfont > > make FETCH_PACKAGES= prepare > > make > > > > Not sure if the top of the trace is of much use. Here it is: > > > > #0 thrkill () at /tmp/-:3 > > #1 0x486dd8c0aacac468 in ?? () > > #2 0x00000c3a34319d0e in _libc_abort () at > > /usr/src/lib/libc/stdlib/abort.c:51 > > #3 0x00000c39b735724b in mem_error () from > > /usr/local/lib/libglib-2.0.so.4201.9 > > #4 0x00000c39b735604f in slab_allocator_alloc_chunk () from > > /usr/local/lib/libglib-2.0.so.4201.9 > > #5 0x00000c39b7355a95 in g_slice_alloc () from > > /usr/local/lib/libglib-2.0.so.4201.9 > > #6 0x00000c39b735606e in g_slice_alloc0 () from > > /usr/local/lib/libglib-2.0.so.4201.9 > > #7 0x00000c396c2675f5 in g_type_create_instance () from > > /usr/local/lib/libgobject-2.0.so.4200.16 > > #8 0x00000c3a19ad2222 in vala_data_type_construct_with_symbol () > > from /usr/local/lib/libvala-0.56.so.0.0 > > #9 0x00000c3a19b4ecae in vala_integer_type_construct () from > > /usr/local/lib/libvala-0.56.so.0.0 > > #10 0x00000c3a19b4f08c in vala_integer_type_real_copy () from > > /usr/local/lib/libvala-0.56.so.0.0 > > #11 0x00000c3a19a9d46f in vala_assignment_real_check () from > > /usr/local/lib/libvala-0.56.so.0.0 > > #12 0x00000c3a19ae54e5 in vala_expression_statement_real_check () > > from /usr/local/lib/libvala-0.56.so.0.0 > > #13 0x00000c3a19aa6a0d in vala_block_real_check () from > > /usr/local/lib/libvala-0.56.so.0.0
