> Scribbling a magic number in the first long word of a free block
> wouldnt be too bad a hit for basic sanity checks. Since you can get
> memory tramples from stuff like stale TLB entries that are far harder
> to find Im less concerned.
That's one of the basic sanity checks I was doing, in an attempt to
ensure the values in a free-block hadn't been corrupted. A block on
a free-list has; magic num, free-list ptrs, bitmap ptrs, etc.
As the min allocation is 32bytes, the allocation ptr would always
be aligned to 32bytes (for both a small and large buffer pools). As
the allocator is a power-of-2, not all allocations fit exactly into one
of the available sizes. It is therefore possbile (sometimes) to
give the allocated block a header (which is easily checked for by
ptr alignment in the free func). As the alignment on a double-word
boundary is important for cache-efficiency and some DMA controls, the
caller could pass a flag to force no-header.
Also, in "debug mode", I was planning maintaining a circular buffer
of the last 32 ops (dumped on panic).
If these checks are sufficent for the allocator, I'll get down and
write a 'decent' version after finishing off the 'slab allocator'.
It will then be a case of suck-it-and-see...
BTW
While working on the 'slab allocator', I was wondering about SMP
features. It would be nice to have per-processor allocation
caches, which lazily coalesces(sp?) to a global cache, which coalesces
to back to the page allocation layer. Similar to Mach's Zone allocator.
This should reduce the number of cache SNOOPs (do I have my
terms right?). I'm not sure on the current SMP status, but at a
glance it appears only one process can be execuing in kernel space
at any given time. Maybe this extension would only be worth the over-
head when parts of the kernel become multi-threaded.