From owner-freebsd-hackers Sun Jan 26 21:50:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18301 for hackers-outgoing; Sun, 26 Jan 1997 21:50:38 -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 VAA18296 for ; Sun, 26 Jan 1997 21:50:35 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id FAA27728; Mon, 27 Jan 1997 05:49:42 GMT Date: Mon, 27 Jan 1997 14:49:41 +0900 (JST) From: Michael Hancock To: proff@suburbia.net cc: hackers@freebsd.org Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: 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, Michael Hancock 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. Oops, as David mentioned, I goofed. The major objects are mach zone and when freed can be allocated as another type later on. The way vnodes are allocated and deallocated is almost TSM, if it weren't for the special allocation case when more vnodes are needed than originally allocated at boot. I'll have to look into how Solaris' SLAB deallocates memory, it's probably not TSM either. Regards, Mike Hancock