Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Jan 1997 17:05:07 +0900 (JST)
From:      Michael Hancock <michaelh@cet.co.jp>
To:        David Greenman <dg@root.com>
Cc:        FreeBSD Hackers <hackers@FreeBSD.ORG>, freebsd-smp@FreeBSD.ORG
Subject:   Re: SLAB stuff, and applications to current net code (fwd) 
Message-ID:  <Pine.SV4.3.95.970127161347.27960A-100000@parkplace.cet.co.jp>
In-Reply-To: <199701262225.OAA08492@root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970127161347.27960A-100000>