From owner-freebsd-hackers  Sun Jan 26 14:44:07 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA29537
          for hackers-outgoing; Sun, 26 Jan 1997 14:44:07 -0800 (PST)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29508
          for <hackers@freebsd.org>; Sun, 26 Jan 1997 14:44:02 -0800 (PST)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22])
          by alpo.whistle.com (8.8.4/8.8.4) with SMTP
	  id OAA17789; Sun, 26 Jan 1997 14:37:51 -0800 (PST)
Message-ID: <32EBDC19.794BDF32@whistle.com>
Date: Sun, 26 Jan 1997 14:35:05 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: proff@suburbia.net
CC: dg@root.com, hackers@freebsd.org, alan.cox@linux.org
Subject: Re: SLAB stuff, and applications to current net code (fwd)
References: <19970126125747.19508.qmail@suburbia.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

proff@suburbia.net wrote:
> 
> > >I not sure how much benefit the SLAB allocator would offer over what we
> > >have.  There's some extra overhead in maintaining a SLAB.
> > >
> > >BTW, SLAB is used in Solaris.
> >
> >    The allocator in BSD is designed to be as fast as possible and trades
> > space efficiency for performance. I'm very skeptical that a SLAB allocator
> > would be any faster than the current allocation algorithm, although it
> > would likely be more space efficient.
> >
> > -DG
> >
> > David Greenman
> > Core-team/Principal Architect, The FreeBSD Project
> >
> 
> I presume the idea is that the cache efficiency of small allocations
> would be substantially improved?
> 
> Cheers,
> Julian <proff@iq.org>

I talked with alan about this at the USENIX conf.
He told me that  originally he looked at using a BSD style allocator,
but that small allocations of mbufs etc all hit the same cache
lines as they were always on powers of two. (obviously)
especially when working on the headers of large packets.

he saw a noticable problem with cache overwrites.

I didn't get it all but probably he could tell us more..
I've CC'd him. He seems very knowledgable about BSD internals 
and not at all the screaming fanatic that we sometimes see in the linux
camp so I really enjoyed the conversation..

julian