Re: [v3] __pool_alloc rework

[Carlo Wood <carlo at alinoe dot com>]

On Tue, Jun 22, 2004 at 11:59:45PM -0500, B. Kosnik wrote:
> 
> >	May I suggest a simple but possibly effective way to speed up the
> >already fast pool_alloc in the mt-case. Well, if you observe, there is
> >only one lock for the pool, while the pool is split up into 128/8 parts.
> >So, a speed up could be definitely achieved by keeping one lock for each
> >part of the pool right?
> 
> Right. I was hoping to do this, but couldn't figure out the linkage bits.
> 
> I think I have it now, and have posted a patch which implements this.

Urgllm

And in what release would this be put?

I hope you will use mt_alloc instead.  If pool_alloc is "fixed" in this
way then I will have to hack access to 128 different locks - and even
figure out which one I need to test (that is going to be hard because
the size of the buffer increase while writing data to 'cout' is not
known upfront - I could increase the buffer with a large fixed size
EVERY call - but that would 1) use too much cpu and 2) need to queue
message more often because it means I *always* need to increase the
buffer size "just in case").  This is going to be a disaster for me :/
No, if this ends up in an official release then I'll have to start
to delay every debug output concerning memory allocations until the
first time there is other debug output - that will take away the
real-time-ness of the memory alloction related debug output in 99.99%
of cases where it is not really _needed_ to do so (because in practise
it would not have led to a deadlock).

Why this change?  What is wrong with Paolo's proposed mt_allocator.h?

Hoping that this is not going to happen,

-- 
Carlo Wood <carlo@alinoe.com>