Comment 30 for bug 1838575

This is a silly but useful distribution check with log10 of the allocation sizes:
Fast:
    108 3
   1293 4
  12133 5
 113330 6
  27794 7
   1119 8
Slow:
    194 3
   1738 4
  17375 5
 143411 6
     55 7
      3 8

I got no warnings about missed calls, but always be aware that some numbers might be off - ususally they are ok for relative comparisons.

So yeah, the slow case just needs to map more smaller pieces as that is all it can find.
That explains the "getting worse with system runtime", and I don#t think there is much that can be done here.

I'll discuss if there is any gain in splitting this from one thread into many (for very huge memory sizes).

P.S. Finally I just want to re-iterate that using hugepages due to their pre-allocation, less fragmentation, less mapping behavior really is the "config" way out of this.