From owner-freebsd-arch Sun Feb 9 11:25:46 2003 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 25E1637B41A for ; Sun, 9 Feb 2003 11:25:44 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 068BD43F3F for ; Sun, 9 Feb 2003 11:25:43 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h19JPWqV031324; Sun, 9 Feb 2003 20:25:32 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Peter Wemm Cc: Alfred Perlstein , Jake Burkholder , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: New kernel allocation API From: phk@phk.freebsd.dk In-Reply-To: Your message of "Sun, 09 Feb 2003 11:16:29 PST." <20030209191629.88B942A8B4@canning.wemm.org> Date: Sun, 09 Feb 2003 20:25:32 +0100 Message-ID: <31323.1044818732@critter.freebsd.dk> 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 In message <20030209191629.88B942A8B4@canning.wemm.org>, Peter Wemm writes: >phk@phk.freebsd.dk wrote: >> In message <20030209075706.GO88781@elvis.mu.org>, Alfred Perlstein writes: >> >> >I may see if I can convert some paths in the kernel to use zones. :) >> >> I have a number of places where zones can be used instead of malloc, >> but since none of the places I have tried previously have resulted >> in measurable performance differences it has not been high on my >> agenda. > >I'd be interested to know what it did to KVA usage on i386. I would expect >to find a more efficient KVA utilization (and memory utilization) due to >better packing of objects instead of the power-of-two roundup that malloc >does. Well, none if it has very large memory footprints, we have like 10-20k of dev_t's and while GEOM sucks up more than that, it is a lot of different sizes so it actually ends up wasting space. struct bio may be a candidate, but we're usually in the low hundreds of those at any time so there may be 30k to save or something. It did do wonders FFS inodes and dinodes, but those come in numbers approaching 100k on my system. sysctl kern.malloc shows where the gains are to be had. Unfortunately, the vfs-cache stores variable length strings... bang# sysctl kern.malloc | sort +0.19 -n | tail -10 MSDOSFS mount 1 256K 256K 1 kobj 80 320K 320K 80 4096 NFS hash 1 512K 512K 1 UFS ihash 1 512K 512K 1 ISOFS mount 1 512K 512K 1 inodedep 144 530K 2645K 299243 128,256 devbuf 455 1004K 1043K 918 16,32,64,128,256,512,1024,2048,4096,16384 GEOM 6081 1533K 1533K 6327 16,32,64,128,256,512,1024,4096 SWAP 2 3281K 3281K 2 64 vfscache 90101 6668K 7708K 1246645 64,128,256 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message