Subject: Re: FREE( s, M_xxxx ) - a bug you don't want to look for!
To: None <tech-kern@netbsd.org>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 06/28/2002 00:40:16
> 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