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

On their own - but the pair start making any macro 20 instructions
A leaf routine doesn't have that much overhead.
Ok if the malloc/free are on a 'common' fast path maybe the inline
version is fine, but I suspect most just increase the memory/cache
footprint.
> 
>  > 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.)

Who allocates KVA?  Off the top of my head I'd guess:
- malloc
- pools
- process u area
- maps for process user data (apart from curproc)
- loadable kernel modules (use malloc?)

Only the first two seem to require indefinite amounts.
(obviously they all may need physical memory for page tables - which
could be dynamically allocated (even in the KVA is finally in the new area!))

Dynamic allocation from an ISR requires that free pages be available
- but I guess the requests are allowed to fail (and the ISR code
will recover).
> 
> Not all pools need to be accessed in interrupt context, and thus those pools
> use a KVA allocator which doesn't pre-reserve space.

ok a subtle difference.  which 'space' is actually pre-reserved?
> 
>  > 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.

Ok what am I missing about direct mapped segments?
Are they 'large' pages mapped with physical == virtual?
If that is so, shouldn't be too hard to make an address -> pool
map work.

	David

-- 
David Laight: david@l8s.co.uk