Re: [PATCH v2] Add malloc micro benchmark

["Ondřej Bílka" <neleai@seznam.cz>]

On Wed, Feb 28, 2018 at 04:56:28PM -0500, DJ Delorie wrote:
> 
> Ond?ej B?lka <neleai@seznam.cz> writes:
> > First for small sizes allocation would be just popping element from
> > thread local single linked list, or calling function to refill lists
> > with enough elements when empty.
> 
> This is basically what tcache does.  Although I tested a few ways of
> pre-filling the cache, there's room for more research there beyond the
> few algorithms I used.  Some folks have been experimenting with "ideal"
> values for tcache_count and tcache_max too.
>
That isn't case, tcache counters slow things down and are unneccessary.
One could establish limits by using tricks in free.

I had different idea for representation now, so I will send it in
separate thread.

 
> > Finally for larger allocations I would use page-based logic as
> > mmaping/remapping/unmapping is about only way to actually decrease
> > memory footprint, I didn't try that much yet.
> 
> Note that mmap() itself is expensive (slow) and there may be a limit on
> how many discrete mapped regions a kernel[*] can support.
> 

For larger its more that one should be aware of paging as to handle
memory allocated from system. One such issue is that often big
allocation doesn't use pages at end. 
For returning memory to system I think that best strategy is something like
 hitting pages that weren't used last second by madvise(dont_need)