On Thu, Jun 27, 2002 at 07:20:48PM +0100, David Laight wrote:

 > Yes - I spotted that, however with the inlined spl() calls the
 > x86 code generated isn't THAT small.

The inlined x86 spl calls are, in fact, quite small.

 > I guess it is more efficient in that it can allocate sizes that are
 > not a power of 2 - however since malloc() is largely 'pool' based
 > it could easily support non-power of 2 sizes [1].
 > If you didn't have to reserve KVA for both malloc and pool use you
 > could allocate the combined KVA space to a single entity.

Uh.  No.

malloc() is safe to use in interrupt context, and therefore has to have
a range of KVA pre-allocated to it.  (I have some thoughts on how to change
this, but it would require a significant rework of the malloc code.)

Not all pools need to be accessed in interrupt context, and thus those pools
use a KVA allocator which doesn't pre-reserve space.

 > Why is that different from malloc ?
 > Both lots of code seem to grab a page and chop it up into bits...

malloc() internally uses the address of the object passed to free()
to determine which bucket the object came from.  This is incompatible
with direct-mapped segments.

 > When trying to get MP code efficient, per processor free lists
 > start being necessary (in order to reduce cache snooping).
 > Seems extreme to do this to both the pool code and malloc
 > when a merged version would suffice.

I am well aware of that.  I have plans to add that to the pool allocator.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>