From owner-freebsd-hackers Sun Jan 26 05:40:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09170 for hackers-outgoing; Sun, 26 Jan 1997 05:40:52 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA09165 for ; Sun, 26 Jan 1997 05:40:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id FAA06943; Sun, 26 Jan 1997 05:40:21 -0800 (PST) Message-Id: <199701261340.FAA06943@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-reply-to: Your message of "Sun, 26 Jan 1997 23:57:47 +1100." <19970126125747.19508.qmail@suburbia.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 05:40:21 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >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. ... >I presume the idea is that the cache efficiency of small allocations >would be substantially improved? We already order the allocations to take advantage of the cache by putting freed chunks at the head of the list within the bucket (thus making them the first candidates for re-allocation). This isn't perfect, of course, but it does get you most of the way there. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project