Lots of warnings due to failing to allocate aligned OS memory

[anarazel]

Hi,

I'm using mimalloc indirectly, via the mold linker. This is mimalloc 2.0.6+ds-2+b1 from debian unstable. On a new linux kernel (v6.1-rc3-158-gee6050c8af96) nearly every use of mold results in a lot of warnings. Here's some of the output with MIMALLOC_VERBOSE=1 set:

mimalloc: process init: 0x7f8dacc9f800
mimalloc: debug level : 2
mimalloc: secure level: 0
mimalloc: using 2 numa regions
mimalloc: option 'show_errors': 1
mimalloc: option 'show_stats': 0
mimalloc: option 'eager_commit': 1
mimalloc: option 'deprecated_eager_region_commit': 0
mimalloc: option 'deprecated_reset_decommits': 0
mimalloc: option 'large_os_pages': 0
mimalloc: option 'reserve_huge_os_pages': 0
mimalloc: option 'reserve_huge_os_pages_at': -1
mimalloc: option 'reserve_os_memory': 0
mimalloc: option 'deprecated_segment_cache': 0
mimalloc: option 'page_reset': 0
mimalloc: option 'abandoned_page_decommit': 0
mimalloc: option 'deprecated_segment_reset': 0
mimalloc: option 'eager_commit_delay': 1
mimalloc: option 'decommit_delay': 25
mimalloc: option 'use_numa_nodes': 0
mimalloc: option 'limit_os_alloc': 0
mimalloc: option 'os_tag': 100
mimalloc: option 'max_errors': 16
mimalloc: option 'max_warnings': 16
mimalloc: option 'max_segment_reclaim': 8
mimalloc: option 'allow_decommit': 1
mimalloc: option 'segment_decommit_delay': 500
mimalloc: option 'decommit_extend_delay': 2
mimalloc: warning: thread 0x7f8da56006c0: unable to allocate aligned OS memory directly, fall back to over-allocation (67108864 bytes, address: 0x7f8d99e00000, alignment: 67108864, commit: 0)
mimalloc: warning: thread 0x7f8da4a006c0: unable to allocate aligned OS memory directly, fall back to over-allocation (67108864 bytes, address: 0x7f8d9e000000, alignment: 67108864, commit: 0)
mimalloc: warning: thread 0x7f8da68006c0: unable to allocate aligned OS memory directly, fall back to over-allocation (67108864 bytes, address: 0x7f8d9e000000, alignment: 67108864, commit: 0)
mimalloc: warning: thread 0x7f8da38006c0: unable to allocate aligned OS memory directly, fall back to over-allocation (67108864 bytes, address: 0x7f8d8fe00000, alignment: 67108864, commit: 0)
mimalloc: warning: thread 0x7f8da68006c0: mi_usable_size: pointer might not point to a valid heap region: 0x7f8d94020080
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: thread 0x7f8da68006c0: (yes, the previous pointer 0x7f8d94020080 was valid after all)
mimalloc: warning: thread 0x7f8da68006c0: mi_usable_size: pointer might not point to a valid heap region: 0x7f8d94020080
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: thread 0x7f8da56006c0: mi_usable_size: pointer might not point to a valid heap region: 0x7f8d8c020080
(this may still be a valid very large allocation (over 64MiB))
mimalloc: warning: thread 0x7f8da56006c0: (yes, the previous pointer 0x7f8d8c020080 was valid after all)
mimalloc: warning: thread 0x7f8da56006c0: mimalloc: warning: thread 0x7f8da68006c0: (yes, the previous pointer 0x7f8d94020080 was valid after all)
mi_usable_size: pointer might not point to a valid heap region: 0x7f8d8c020080
(this may still be a valid very large allocation (over 64MiB))
...

I created a tracepoint on probe_libmimalloc:mi_os_mem_alloc. The requests for the 64MB aligned allocation come from within mimalloc itself. Either below mi_reserve_os_memory() or mi_segments_page_alloc().

Looking further, I see that an MAP_FIXED mmap fails to return memory at that address:

ld 237496 [005] 67637.402262:                syscalls:sys_enter_mmap: addr: 0x2006c000000, len: 0x04000000, prot: 0x00000000, flags: 0x00000022, fd: 0xffffffff, off: 0x00000000
..
ld 237496 [005] 67637.402281:                 syscalls:sys_exit_mmap: 0x7f022fe00000

As far as I can tell there are no conflicting mmap requests made be mimalloc.

My vague suspicion is that this is related to linux promoting one of the pages before / after to use transparent huge pages. The region after did get converted by THP:

20070000000-20071000000 rw-p 00000000 00:00 0 
Size:              16384 kB
...
AnonHugePages:     14336 kB

That region was concurrently allocated by another thread that finished before the "failing" MAP_FIXED:

ld 237496 [005] 67637.402262:                syscalls:sys_enter_mmap: addr: 0x2006c000000, len: 0x04000000, prot: 0x00000000, flags: 0x00000022, fd: 0xffffffff
, off: 0x00000000
ld 237495 [002] 67637.402262:                syscalls:sys_enter_mmap: addr: 0x20070000000, len: 0x04000000, prot: 0x00000000, flags: 0x00000022, fd: 0xffffffff, off: 0x00000000
ld 237495 [002] 67637.402272:                 syscalls:sys_exit_mmap: 0x20070000000
ld 237496 [005] 67637.402281:                 syscalls:sys_exit_mmap: 0x7f022fe00000

It's possible that this is just a short term issue in linux and will get fixed. But it might also be better to not allocate neighboring segments concurrently.

It might be helpful to note the requested address in the warning. Could the "mi_usable_size: pointer might not point to a valid heap region" warnings be avoided in this case?

Regards,

Andres

[daanx]

Thanks Andres for your report. Note that the warnings in this case are a bit "pedantic": they can be useful to debug performance problems but in principle the "overallocation" path works fine on Linux (just a tad slower). If Linux would have MAP_ALIGNED (as in BSD) this problem would go away. I like your suggestion though of trying to avoid allocating close to other threads... I give it some thought if this can be done nicely.

The "pointer might be invalid" warning is not generally avoidable for huge blocks (> MI_SEGMENT_SIZE).. but can be ignored if the next message says it was ok after all :-). Hmm, I think in debug mode I can actually improve the precision of the messages as it doesn't matter if it is_in_heap_region test takes a bit longer in debug mode -- I'll try to fix that!

[daanx]

Turns out to be hard to really fix the warning in mi_usable_size but I made a linux specific check to suppress the warning in the latest dev-slice.

[orlitzky]

I just got a new machine (riscv/musl) and am seeing these warnings now. For example,

$ MIMALLOC_VERBOSE=1 gcc $CFLAGS $LDFLAGS main.c 
mimalloc: process init: 0x3FB78BEDB0
mimalloc: debug level : 2
mimalloc: secure level: 4
mimalloc: mem tracking: none
mimalloc: using 1 numa regions
mimalloc: warning: unable to allocate aligned OS memory directly, fall back to over-allocation (size: 0x2000000 bytes, address: 0x003FB5400000, alignment: 0x2000000, commit: 1)
mimalloc: option 'show_errors': 1 
mimalloc: option 'show_stats': 0 
mimalloc: option 'verbose': 1 
mimalloc: option 'eager_commit': 1 
mimalloc: option 'arena_eager_commit': 2 
mimalloc: option 'purge_decommits': 1 
mimalloc: option 'allow_large_os_pages': 0 
mimalloc: option 'reserve_huge_os_pages': 0 
mimalloc: option 'reserve_huge_os_pages_at': -1 
mimalloc: option 'reserve_os_memory': 0 KiB
mimalloc: option 'deprecated_segment_cache': 0 
mimalloc: option 'deprecated_page_reset': 0 
mimalloc: option 'abandoned_page_purge': 0 
mimalloc: option 'deprecated_segment_reset': 0 
mimalloc: option 'eager_commit_delay': 1 
mimalloc: option 'purge_delay': 10 
mimalloc: option 'use_numa_nodes': 0 
mimalloc: option 'disallow_os_alloc': 0 
mimalloc: option 'os_tag': 100 
mimalloc: option 'max_errors': 32 
mimalloc: option 'max_warnings': 32 
mimalloc: option 'max_segment_reclaim': 10 
mimalloc: option 'destroy_on_exit': 0 
mimalloc: option 'arena_reserve': 1048576 KiB
mimalloc: option 'arena_purge_mult': 10 
mimalloc: option 'purge_extend_delay': 1 
mimalloc: option 'abandoned_reclaim_on_free': 1 
mimalloc: option 'disallow_arena_alloc': 0 
mimalloc: option 'retry_on_oom': 400 
mimalloc: reserved 1048576 KiB memory

Is there anything I should configure to make the aligned allocation succeed, or is it doomed to the overallocation path? (In that case, is there a way to hide the warning?)

[daanx]

Very nice that you have a riscV machine -- I'm jealous :-).
Usually, aligned allocation should succeed -- what OS are you using? Is it 64-bit?
(if you look at src/prim/unix/prim.c usually there is another warning message if direct or hinted aligned allocation fails but I don't see it in your output so that is a bit strange)

[orlitzky]

Um, linux? :)

... but due to the weird hardware, that's not the whole story. I'm running a Gentoo userland on the musl C library, but the kernel is a fork of the 6.1.x stable branch: https://github.com/sophgo/linux-riscv

I've also been reconfiguring the kernel myself, trying to figure out what hardware is actually in the box and how to make it work. So it's not even a nice 6.1.x with all modules and features enabled. I know mimalloc is sensitive to things like huge page support, madvise, access to /proc... it is 64-bit though. (And I haven't turned off anything too important, I also hand-built the amd64 kernel I'm typing this on.)

If you think it should succeed, I can always add a bunch of printf statements and try to allocate a buffer for "Hello, World!"

[daanx]

Hmm, that is strange; I see now that (in src\prim\unix\prim.c that the extra messages are trace messages, can you rerun with MIMALLOC_VERBOSE=2 (or 3?) and see if there is an extra message (saying "hinted" or "directly" allocated). ?

I wonder if the aligned hint method is failing where mimalloc tries to allocate in a 2TiB+ region in the address space.

[orlitzky]

Sure thing:

$ MIMALLOC_VERBOSE=3 gcc $CFLAGS $LDFLAGS main.c 
mimalloc: process init: 0x3F83C88DB0
mimalloc: debug level : 2
mimalloc: secure level: 4
mimalloc: mem tracking: none
mimalloc: using 1 numa regions
mimalloc: unable to directly request hinted aligned OS memory (error: 2 (0x02), size: 0x2000000 bytes, alignment: 0x2000000, hint address: 0x050ADE000000)
mimalloc: warning: unable to allocate aligned OS memory directly, fall back to over-allocation (size: 0x2000000 bytes, address: 0x003F81800000, alignment: 0x2000000, commit: 1)
...

[orlitzky]

Interestingly enough, the warnings that I'm seeing during regular use go away with -DNDEBUG. I can still see them with MIMALLOC_VERBOSE=1 (or higher), but if I compile mimalloc with -DNDEBUG, then I don't see them when I'm just trying to run my linker.

[orlitzky]

I think I figured this out. It looks like RISC-V has several different virtual memory layouts,

https://www.kernel.org/doc/html/v6.11-rc7/arch/riscv/vm-layout.html

And I've got as CPU that uses SV39. Based on that chart it, I think the hint area that mimalloc wants to use is unusable, and that's why mmap consistently ignores the (aligned) hint and gives me back something unaligned. I was able to make the warning go away by hacking MI_HINT_BASE, MI_HINT_AREA, and MI_HINT_MAX to much smaller values.