Date: Fri, 1 Mar 2002 19:55:24 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG> Subject: Re: Slab allocator update Message-ID: <200203020355.g223tOn49150@apollo.backplane.com> References: <20020301214243.B43446-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:I lost a lot of my performance gains when I replaced malloc. malloc(9) is
:extremely fast. I finally cought up to it again with the per cpu queues,
:but there is still extra overhead. There is an extra function call, and
:then in the free path I have to do a hash lookup on the page. This is
:because I don't have the freed size when the data is returned, and I need
:to find out what zone it came from. The hash table is slightly smaller
:than the original kmemusage array and should have minimum collisions.
I've found that free(ptr) can usually be turned into
blahblah_free(ptr, bytes) almost universally in programs, and the
kernel MALLOC is no exception. The size is known at free time
in virtually all cases, even for strings. But that would mean a change in
the API.
It might be beneficial to introduce two versions of your free function,
one which does not require the size and another, faster version which
does, and then slowly adjust the kernel to use the new function as well
as add sanity checks for INARIANTS to ensure we don't accidently leak
or corrupt memory by specifying the wrong size.
-Matt
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?200203020355.g223tOn49150>