Re: RFC on mt_allocator.h

[Benjamin Kosnik <bkoz at redhat dot com>]

Hi Stefan.

> The main issue is how to set these values/settings since they are
> "global" and cannot be passed as arguments but rather must be set at
> compile time (using defines, commandline options, functions to be
> called- I don't know) or at startup using some env variables?

I would imagine that you could set allocation size dynamically, with an
accessor member function. This would probably best be in a base class
that is not a template. Perhaps Gaby or others have more interesting
design ideas?

This is applicable to

Item 1: Minimum memory in freelists
Item 4: Maximum block size.

Anyway. On to the other items!

Item 2: Allocate chunks of memory directly to threads when freelist is
empty

> One approach to improve this behaviour and to minimize global locking
> would be to allocate chunks of memory directly to threads if the own
> freelist is empty. Today, if the threads own freelist is empty the
> global freelist for that size is locked, a block removed from this
> list, the global list is unlocked and the memory is returned. When
> there are no free blocks in the global list either, a chunk of memory
> is allocated and a new list is created within that memory (based on
> the blocksize). With this change, if a threads freelist for a certain
> blocksize was empty, a chunk of memory would be allocated by that
> thread, a list created and the memory returned. Subsequent requests
> could then be satisfied without locking.

In general, anything you can do to reduce global locking and calling the
underlying allocator the better. I'm not quite sure if this should be
configurable, or just the default. Do you have performance numbers on
this?

Item 3: Lingering freelists, reusing thread-ids.

> Q: Should the behaviour of the thread_id freelist be changed so that
> thread id's
>    are reused as soon as possible and make it possible not to return
>    memory to global pool? 

I would think this would be the best approach to take, and fits in with
2. Basically, after memory is allocated on a freelist, don't delete it
and store it away.

However, perhaps I'm missing something obvious. It would be interesting
to try this approach vs. current approach with the performance tests for
allocators.

Item 5: Option to clear memory when it's deallocated 
I think this is an interesting idea, and obviously useful, but couldn't
you do this in another allocator, that wraps this one? See
debug_allocator for more info.


Issues not addressed in your RFC:

1) Please come up with some names that aptly describe exactly what this
allocator is doing. The goal is for people, when confronted with the
allocators in ext/ to have an idea what each one does. 

2) Please, I beg you, document this allocator. The concepts in your
initial email is a good place to start.

-benjamin