Re: Getting rid of kmem_map

[Bosko Milekic <bmilekic@xxxxxxxxxxxxxxxx>]

On Sun, Aug 24, 2003 at 08:37:07PM -0700, Matthew Dillon wrote:
>     As I begin work on the slab allocator I have taken a good look at the
>     use of kmem_map and kernel_map.  kmem_map basically exists to avoid
>     deadlocks between interrupts trying to allocate memory (e.g. through
>     zget()) and the mainline system.
> 
>     But all of our 'slow' interrupts and software interrupts are now threads,
>     and they can theoretically block on kernel_map without creating an
>     issue other then high interrupt latency, which we can address elsewhere.
> 
>     I will have to review our 'fast' interrupts (basically the clock interrupts
>     and maybe the serial interrupts), but I don't think these interrupts 
>     allocate any memory.  
> 
>     I believe this means that we can do away with kmem_map in relative
>     safety.  Being able to do so will significantly reduce the number of
>     memory related special cases in the system.  In particular the entire
>     kernel_map will become available for allocations by malloc/zalloc/slab.

  This is something we're likely going to be doing in FreeBSD, too
  (getting rid of kmem_map), at least in -current.  You are right in
  that the distinction is no longer necessary (I think) and that, in
  fact, we may get overall less fragmentation in the long run.

  Another thing that would be nice to see is more pro-active action to
  reduce _map_ fragmentation in VM. 

>     If I can successfully do this tonight and tomorrow I think I may spend
>     the rest of the week converting malloc and zalloc entirely over to 
>     the slab allocator.  zalloc in particular has always been a thorn in our
>     side due to the type-stable nature of zfree(), but in reality there are
>     only a few places where the type stability is actually necessary (like
>     the proc structure) and those could probably be converted to simple
>     per-cpu freelists.

  There are also [at least] the net PCBs.

> 						-Matt

-- 
Bosko Milekic  *  bmilekic@xxxxxxxxxxxxxxxx  *  bmilekic@xxxxxxxxxxx
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/