This is a major gotcha with mimalloc: https://pwy.io/posts/mimalloc-cigarette/. I'd go so far as to say this behavior (relying solely on periodic calls to malloc/free on _every_ thread to tick the thread-local upkeep) could disqualify it as a libc malloc replacement. In a language with safepoints you could have the runtime insert periodic calls to mi_collect() for every thread, but that shouldn't be required to drive a libc malloc.
Mimalloc Cigarette: Losing one week of my life catching a memory leak

How do you solve a memory heisenbug?

pwy.io
@pervognsen I've had mimalloc randomly doing 2 milliseconds of deferred cleanup when I wanted to allocate memory. Was not happy about that.
@morten_skaaning Yeah, a lot of that is inherent to the problem space--you generally have to trade some amount of latency for throughput.
@pervognsen ironically my goal was to save 2 ms 😅
@morten_skaaning But to be clear, 2 ms is definitely way too high under normal circumstances. You could probably smooth that out by making mimalloc-specific calls to mi_collect() in your main loop or whatever.