Date: Fri, 1 Mar 2002 22:18:40 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG> Subject: Re: Slab allocator update Message-ID: <20020301214243.B43446-100000@mail.chesapeake.net> In-Reply-To: <16960.1015015703@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Mar 2002, Poul-Henning Kamp wrote: > > I ran an earlier version of JeffR's patches on my testbox for > a couple of weeks and saw a pretty consistent speedup in the > order of single digit percentages on most of what I timed. > > I don't know if the current patch set is significantly changed > in any important aspect since then. 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. This organization also eliminates some potential space savings on large objects. The original solaris allocator could force allocations to waste less than 8% of memory. They acomplish this by allocating several contiguous pages and then cutting them into pieces. Since I have to do a hash look up on the page that a particular allocation came from it may not be the starting page for that slab. This would force me to insert a slab into the hash table for every page it owns, and I'd have to provide extra linkage information for this. The other alternative is to use resource tags for every malloc allocation. It would probably be a pointer to the slab that lived just before the allocated data. This would give much higher overhead for small allocations, but save space on large allocations. I intend to gather statistics on which sizes are used the most frequently so I can pick the most appropriately sized malloc zones, and when I gather this data I'll know whether it's a win to lose space on small allocations to save it on the really large ones. I have been considering further unionizing the slab structure to make it suitable for zone style allocations as well as malloc style allocations. Malloc style allocations don't need the type stable storage overhead. The links can be stored directly in the memory. This would yield further space optimizations, and speed optimizations. I could share the front end per cpu cache code and the zone configuration code, but I'd have to provide another slab_zalloc for malloc that setup linkage correctly. Anyway, there is still a lot of work that can be done to improve this. Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > 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?20020301214243.B43446-100000>