From owner-freebsd-arch Wed Oct 9 12:16:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4A5237B401 for ; Wed, 9 Oct 2002 12:16:16 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id A1E2E43E42 for ; Wed, 9 Oct 2002 12:16:16 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 14819 invoked by uid 1000); 9 Oct 2002 19:16:17 -0000 Date: Wed, 9 Oct 2002 12:16:17 -0700 (PDT) From: Nate Lawson To: arch@freebsd.org Subject: slab allocator performance? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: >>On 09-Oct-2002 Julian Elischer wrote: >> there is a thread_allocator that allocates threads on demand. >> >> Actually the process ahs a couple of spare threads "Up its sleave" >> so it doesn't have to go to teh thread allocator every time.. > >Which kind of defeats the point of letting the slab allocator manage >memory from a larger whole-view perspective. :-P I've written a driver that used to use a private struct pool. It mallocs/frees about 120 bytes per 32KB transaction. I'm curious how others are using the allocator and what kind of performance/usage it is best at. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message