Date: Fri, 7 Feb 2003 21:09:33 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Gary Thorpe <gathorpe79@yahoo.com> Cc: 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: <20030207205529.K72073-100000@mail.chesapeake.net> In-Reply-To: <20030206193815.71344.qmail@web41205.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: 1) Resolve the kernel virtual address into the physical page by using pmap_kextract. This is _expensive_. 2) Follow the page's object pointer which is overloaded to mean slab. 3) Follow the slab's back pointer to it's zone. 4) Free the item to the zone passing in the slab pointer as an optimization. This could go something like this: 1) Lookup the zone in a small table based on the size passed to free. 2) Free the item to that zone 3) Lookup the slab address based on the address of the object or the zone's hash table. The reason that you cant do this now is because you don't know if the item's slab structure is allocated along with the item. So you cant just use address mask tricks to lookup the slab. This is done to support large objects. > Its too bad it cannot directly find the > slab by using the pointer value....how does free() search for the > allocated block? The old code used a large fixed size array that represented all of kmem_map. This no longer works because the allocator can return pages that are outside of kmem map. It does this on alpha, ia64, and sparc64 to use direct mapped regions of address space for kernel memory. > Also, with more arguments, the programmer can make more mistakes. What > happens if the wrong size is passed to free? It should still work, but > it will be slower right? I agree. You'd panic because the item would not be found in that zone. I think we should ignore this until someone is prepared to really address all the issues surrounding this api. I don't see any sense in defining two new entry points when they give no distinct capabilities. Cheers, Jeff 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?20030207205529.K72073-100000>