Some rough notes on my kmalloc patches.

The alternative kmalloc/page_alloc:

  An alternative to kmalloc/page_alloc that doesn't use a power of 2
  allocator. 

  Basically this adds two new files,  linux/mmnommu/kmalloc2.c and
  linux/mmnommu/page_alloc2.c,  and a config option in the "Kernel Hacking"
  menu to enable it.

  It allocates the minimum number of pages required to satisfy each request.
  Its not super fast,  but it should be good for single page allocations and
  I haven't noticed any general degradation.

A per process heap:

  A heap is implemented for each process (only binfmt_flat for now).
  It is not a full blown VM heap.  What it does is use the slack space at
  the end of the process as a heap (accessed through brk() and sbrk() which
  are also included in the patch).

  When using the default kmalloc/page_alloc,  this can give you a fair
  chunk of memory to play with.  When it runs out just go back to using
  mmap.  To be useful this needs a malloc that knows about brk()/sbrk()
  and knows to drop back to mmap when it fails.

Another malloc:

  A malloc (lib/libsmalloc/...) which knows about the kernel
  allocators inefficiencies and tries to get around them.  This was
  actually the first thing I tried while porting GNU Zebra which did a
  lot of small mallocs (~2300 8-32 bytes mallocs !).  The default uClinux
  has about 56 bytes of overhead per malloc which kills an app that does
  this kind of thing.  This version of malloc knows how to use the
  new brk() and sbrk() calls as well.

  The big problem with this malloc is that it never returns memory to the
  system (until process exit).  It does re-use memory it has already
  allocated and freed,  so its not all bad,  but it could be better :-)
  
  If you have an app that does a lot of small mallocs,  and doesn't free
  them, link against this malloc,  it should save you quite a bit.