Re: New slab allocation (pre-alpha)

From: Mark Hemment (markhe@nextd.demon.co.uk)
Date: Mon Jun 12 2000 - 17:57:01 EST


Hi,

> Mark Hemment wrote:
> >
> > o Ability to add new general size caches on the fly.
> > This is coded, but never tested. Again, will probably cause a
> > panic/lockup.
> > To avoid having to lock the general cache linkage for SMP
> > (searched from a kmalloc(), so a lock would be bad), some
> > "tricks" are pulled.
> >
>
> I don't know if this is a step in the right direction:
> If we know the general cache sizes at compile time, we can use
> __builtin_constant_p() to optimize fixed kmallocs, and most kmallocs are
> fixed size.

The "standard" general size cache nodes are in a contigious block of
allocated memory, for many reasons (not just for __builtin_constant_p()).
So there is absolutely no reason this optimisation couldn't be applied.
Look at the code.
  The ability to add general size caches is important. Go look at the
code in net/core/skbuff.c, commented out function, skb_add_mtu(). I don't
add features without a reason.

Mark

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:26 EST