lkml.org 
[lkml]   [1997]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans