From owner-freebsd-arch  Sun Mar  3 12:43:45 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87])
	by hub.freebsd.org (Postfix) with ESMTP id 2F3D037B402
	for <arch@FreeBSD.ORG>; Sun,  3 Mar 2002 12:43:38 -0800 (PST)
Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc54.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020303204332.KUBS1214.rwcrmhc54.attbi.com@gateway.posi.net>;
          Sun, 3 Mar 2002 20:43:32 +0000
Received: from localhost (kbyanc@localhost)
	by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g23KhU621433;
	Sun, 3 Mar 2002 12:43:30 -0800 (PST)
	(envelope-from kbyanc@posi.net)
X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs
Date: Sun, 3 Mar 2002 12:43:29 -0800 (PST)
From: Kelly Yancey <kbyanc@posi.net>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Alfred Perlstein <bright@mu.org>,
	Jeff Roberson <jroberson@chesapeake.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG>
Subject: Re: Slab allocator update
In-Reply-To: <200203021815.g22IF0e55311@apollo.backplane.com>
Message-ID: <20020303120514.W21325-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

On Sat, 2 Mar 2002, Matthew Dillon wrote:

> :I think that the overhead and inconvience to store the size of the
> :allocations may be too much for us to deal with.
>
>     I have to disagree here.  I have a lot of experience converting
>     malloc()/free() based systems to other types of memory allocators
>     where the 'free' requires a size.  It's utterly trivial.  The size
>     is known trivially in 99% of the cases.
>

  As someone who has used one of Matt's other allocators in which free()
requires a size, I have to agree with him.  Adding a size parameter to free
offloads the management of the size information from the software to the
programmer.  While it may not be ideal for general purpose software, it
makes very good sense when you are looking to optimize software for speed.

  Kelly
  kbyanc@{posi.net,FreeBSD.org}


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message