Date: Sat, 2 Mar 2002 03:34:59 -0800 From: Alfred Perlstein <bright@mu.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG Subject: Re: Slab allocator update Message-ID: <20020302113459.GU77980@elvis.mu.org> In-Reply-To: <20020302055809.B43446-100000@mail.chesapeake.net> References: <20020302081728.GR77980@elvis.mu.org> <20020302055809.B43446-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@chesapeake.net> [020302 03:07] wrote: > > > 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? As I said this is the right thing to do, make the tradeoff for speed. using .1% of the system memory in order to effeciently manage the pool seems like a worthwhile tradeoff. You could halve this requirement by doing roundoffs to 2xPAGE_SIZE and half it again by making it a 16 bit integer pointing into an indirect array, but that's over optimizing for space imo. I think that the overhead and inconvience to store the size of the allocations may be too much for us to deal with. Anyhow, you said you had some performance issues, using the simple hash will hopefully make the code smaller and more simple thereby speeding it up some. Why not try that and see if you get better numbers. All the enhanced features are nice, but it'd be a lot cooler if we could get some added performance out of this as well. As a side note, have you considered (or does it allow this already?) the ability to have a slab that is a multiple of PAGE_SIZE in order to more effeciently pack structures? Lastly it might make sense to have a double map, so you have an array of pointers to pages that contain pointers to your slab meta-data, then you only need to allocate another page for this when you grow the arena, this may cause too much complication though, but it may offer an improvement over hash chaining. -- -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020302113459.GU77980>