Messages in this thread | | | Date | Wed, 6 Aug 1997 23:35:42 +0200 | From | Martin von Loewis <> | Subject | Re: The Slab Allocator (Was: Re: New dcache not using slab allocator?) |
| |
> Do you need a guarantee against blocking or disabling interrupts, or do > you just need very fast allocation? I could propose a very simple front > end with a typical allocation time of 2 xchg instructions (+ one pointer > dereference), a worst case same as current slab, and no need for > per-engine queues.
You are probably thinking of a mechanism where you have a list of free objects, and do the allocation inline (invoking SLAB if the list is empty). I was wondering myself why this has not been done. Here a couple of possible reasons: - risk of fragmentation. you somehow have to choose when to return memory to SLAB, otherwise you risk eating too much memory. - race conditions: for file system code, and possible process management, interference with interrupt handlers is not an issue. However, on SMP systems, dirty things can happen. Per-processor might help, but also might worsen the first problem: One processor always allocates from SLAB because the list is empty, the other one always puts the released entry into its list. - limited functionality: I still don't understand what those *structors are used for - but you certainly could not support them in 2 xchg instructions. The only application I can think of is that you don't need to re-initialize items returned from the front-end list, if they are left in the state they had upon free(). The first problem could be solved by putting an upper limit on the number of cached objects (a small number, like 4 or 8 - fine tuning would be subject to profiling). Could the second problem be solved with bus locking?
So why is this a bad idea? :-)
Regards, Martin
| |