From owner-freebsd-hackers Sun Jan 26 15:27:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01529 for hackers-outgoing; Sun, 26 Jan 1997 15:27:28 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA01524 for ; Sun, 26 Jan 1997 15:27:24 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA25209; Sun, 26 Jan 1997 23:26:48 GMT Date: Mon, 27 Jan 1997 08:26:48 +0900 (JST) From: Michael Hancock To: David Greenman cc: proff@suburbia.net, hackers@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701261235.EAA06772@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 26 Jan 1997, David Greenman wrote: > >On Sun, 26 Jan 1997 proff@suburbia.net wrote: > > > >> Can anyone inform me what a SLAB allocator is, and if so, would freebsd > >> benefit from one? > >> > > > >It's a chunk of memory that you put multiple kernel objects of the same > >type into. We have a modified mach zone allocator. They're both type > >stable memory allocators. > > The memory allocator in BSD is *not* type-stable. For SMP it might more make sense to create typed global pools to allocate objects per zone, than putting effort into a SLAB allocator. > 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. It did seem easier to color the cache with the SLAB implementation. I don't remember the results of John's page coloring work to distribute hits in the cache. > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project >