Date: Fri, 7 Feb 2003 18:27:22 -0800 From: Alfred Perlstein <bright@mu.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Gary Thorpe <gathorpe79@yahoo.com>, Julian Elischer <julian@elischer.org>, Peter Wemm <peter@wemm.org>, Dag-Erling Smorgrav <des@ofug.org>, arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030208022722.GB88781@elvis.mu.org> In-Reply-To: <20030207205529.K72073-100000@mail.chesapeake.net> References: <20030206193815.71344.qmail@web41205.mail.yahoo.com> <20030207205529.K72073-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@chesapeake.net> [030207 18:10] wrote: > On Thu, 6 Feb 2003, Gary Thorpe wrote: > > > How will it make it faster? By jumping to the group of memory slabs > > that would match that size? > > Yes. Right now in malloc you have to look up the zone based on the > address. I have a hack that lets us do this in constant time. It > basically goes like this: *snip* It seems that you've missed reading the original allocator or something, there's a cheap way to do this that doesn't require too much overhead. Since you know the max size of the malloc arena you simply allocated "size of malloc arena" / granulatity to realize "number of pointers". You then allocate "number of pointers". Now as you allocate portions of the malloc arena for slabs you point the pointers corresponding to the granule at the slab. Now you can take any pointer and figure out which granule it is associated with in O(1) time. Yes there is a space tradeoff, but it avoids this pmap_kextract nonsense and multiple pointer dereferences. -Alfred 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?20030208022722.GB88781>