From owner-freebsd-hackers  Sun Jan 26 13:25:32 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA25104
          for hackers-outgoing; Sun, 26 Jan 1997 13:25:32 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25096;
          Sun, 26 Jan 1997 13:25:29 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02284; Sun, 26 Jan 1997 14:08:43 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199701262108.OAA02284@phaeton.artisoft.com>
Subject: Re: Possible projects?
To: hsu@freefall.freebsd.org (Jeffrey Hsu)
Date: Sun, 26 Jan 1997 14:08:43 -0700 (MST)
Cc: kneel@ishiboo.com, hackers@freefall.freebsd.org
In-Reply-To: <199701260732.XAA23320@freefall.freebsd.org> from "Jeffrey Hsu" at Jan 25, 97 11:32:57 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> You could try converting the kernel memory allocator to a slab
> allocator.  See the Unix Frontiers books for more details and
> ideas for other projects.

Please see my other posting.  I know it isn't a pure SLAB allocator,
but the interface is we use is a SLAB interface.

Also, there are many cases where a pure SLAB allocator is a very, very
bad idea.

Using an impure allocator could win 1.1 times performance over a SLAB
allocator in the up case, and 100 to 1000 time performance in the MP
case.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.