From owner-freebsd-smp Mon Jan 27 00:05:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA25101 for smp-outgoing; Mon, 27 Jan 1997 00:05:17 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA25096; Mon, 27 Jan 1997 00:05:14 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id IAA28518; Mon, 27 Jan 1997 08:05:07 GMT Date: Mon, 27 Jan 1997 17:05:07 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: David Greenman cc: FreeBSD Hackers , freebsd-smp@FreeBSD.ORG Subject: Re: SLAB stuff, and applications to current net code (fwd) In-Reply-To: <199701262225.OAA08492@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Added cc to smp] On Sun, 26 Jan 1997, David Greenman wrote: > >Vahalia cites a paper: > > "Efficient Kernel Memory Allocation on Shared Memory > > Multiprocessors" > > McKenney, P.E. and Slingwine, J. > > Proceedings of USENIX, Winter, 1993 > > > >Which shows the sequent code to be faster than the McKusick-Karels > >algorithm by a factor of three to five on a UP, and a factor of > >one hundred to one thousand on a 25 processor system. > > I haven't read that paper, but I suspect that the numbers are wrong due > to spl* having high overhead back then. Since Bruce's "fast interrupt" code, > spl* is almost free, and this changes things greatly. The situation might > change slightly in MP systems, but the total time inside of malloc is so small > that I really doubt that synchronization/serialization will ever be a > significant problem. > If subsystems used TSM it would be faster still at the expense of being even less space efficient. Objects would never be free'd in the malloc/free sense, but put on a typed free list. The operations of moving from list to list is even cheaper than malloc/free and synchronization/serialization is easier, even more so in MP environments. In this case, the performance of malloc/free would be largely irrelevant. However, the underlying allocator's ability to distribute hot objects across the processor cache might become more important. TSM probably wouldn't go over with those that want to run FBSD on systems with 8MB of RAM. It'd probably be the way to go for SMP systems though. BTW, SLAB isn't type stable either. There's an operation kmem_cache_reap() that returns a SLAB whose objects are all free to the page level allocator. TSM on top of a SLAB allocator might be interesting. It would negate the extra management overhead of the SLABs and be able to take advantage of processor cache coloring at the same time. Regards, Mike Hancock