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/27/2002 19:20:48
On Thu, Jun 27, 2002 at 10:11:03AM -0700, Jason R Thorpe wrote:
> On Thu, Jun 27, 2002 at 05:11:08PM +0100, David Laight wrote:
> 
>  > If you could 'assert' it you could force a call to malloc() instead.

I wasn't aware of the gcc __builtin_constant_p() function.
> 
> The whole point of using a constant size in this case is for the
> compiler to do constant folding.  Take a look at the macros involved.
> If you don't use a compile-time constant, it's evaluated at run-time,
> with the associated explosion in code size.

Yes - I spotted that, however with the inlined spl() calls the
x86 code generated isn't THAT small.
> 
>  > I have my doubts as to how much these macros save?
>  > Maybe I'll time a kernel build with them on/off.
> 
> If you use DIAGNOSTIC, they're already off.
> 
>  > I also suspect that replacing all the 'pool' allocates with
>  > (a slightly modified) malloc() would be benefitial.
> 
> Huh?  We specifically switched from malloc to pool in many places because
> the pool allocator is more memory-efficient, and can also allocate KVA from
> different VM maps (thus reducing the pressure on malloc's kmem_map).

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.
> 
> (pools also allow you to take advantage of direct-mapped segments, like
> KSEG0 on MIPS/Alpha, thus greatly reducing TLB usage on those platforms.)
Why is that different from malloc ?
Both lots of code seem to grab a page and chop it up into bits...

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.

	David

[1] select the freelist using:
	if (size > ALLOCATE_PAGES)
		return allocate_pages( size );
	pool = size_map[ size / 16 ];
	item = poll_table[ pool ].head;
	...
An array of 256 bytes is all it needs - (and a cache miss on the
table entry!)


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