From owner-freebsd-arch Sat Mar 2 3: 7:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id 85CCB37B400 for ; Sat, 2 Mar 2002 03:07:28 -0800 (PST) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g22B7KO79716; Sat, 2 Mar 2002 06:07:21 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 2 Mar 2002 06:07:20 -0500 (EST) From: Jeff Roberson To: Alfred Perlstein Cc: Matthew Dillon , Poul-Henning Kamp , Julian Elischer , Subject: Re: Slab allocator update In-Reply-To: <20020302081728.GR77980@elvis.mu.org> Message-ID: <20020302055809.B43446-100000@mail.chesapeake.net> 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 > What the hell? > > Why isn't there a pointer per page or PAGE_SIZE*N that points to > the bucket? This is a simple space/speed tradeoff that we want > to make for speed. With that in place all you need to do is > round down the Free'd location to the nearest page_size and > do a lookup into the perfect hash for that page. > There is right now, that's the mallochash. It works as long as the base page for each item in the slab is the same. That is to say, if you have a slab with multiple pages it can only hold one item. This is because you may have collisions, in which case you need to have a link. There is only space set aside in each slab for one link. If you want to completely avoid collisions you define a fixed bucket for every possible page. That is how the current malloc implementation works. That's really not a problem when you have a fixed size space for the heap (ie kmem_map). But really the goal is to manage the kernel address space in one map. If you want to hold a pointer to every possible page in a 1 gigabyte address space, assuming 4kb pages, you're using 1MB for this map. I guess we could do it, and sparsely fill this array. That seems like a somewhat reasonable solution as well, although more costly in terms of memory usage than providing the size on free. Comments? Jeff > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message