Date: Sun, 26 Jan 1997 14:35:05 -0800 From: Julian Elischer <julian@whistle.com> To: proff@suburbia.net Cc: dg@root.com, hackers@freebsd.org, alan.cox@linux.org Subject: Re: SLAB stuff, and applications to current net code (fwd) Message-ID: <32EBDC19.794BDF32@whistle.com> References: <19970126125747.19508.qmail@suburbia.net>
next in thread | previous in thread | raw e-mail | index | archive | help
proff@suburbia.net wrote: > > > >I not sure how much benefit the SLAB allocator would offer over what we > > >have. There's some extra overhead in maintaining a SLAB. > > > > > >BTW, SLAB is used in Solaris. > > > > The allocator in BSD is designed to be as fast as possible and trades > > space efficiency for performance. I'm very skeptical that a SLAB allocator > > would be any faster than the current allocation algorithm, although it > > would likely be more space efficient. > > > > -DG > > > > David Greenman > > Core-team/Principal Architect, The FreeBSD Project > > > > I presume the idea is that the cache efficiency of small allocations > would be substantially improved? > > Cheers, > Julian <proff@iq.org> I talked with alan about this at the USENIX conf. He told me that originally he looked at using a BSD style allocator, but that small allocations of mbufs etc all hit the same cache lines as they were always on powers of two. (obviously) especially when working on the headers of large packets. he saw a noticable problem with cache overwrites. I didn't get it all but probably he could tell us more.. I've CC'd him. He seems very knowledgable about BSD internals and not at all the screaming fanatic that we sometimes see in the linux camp so I really enjoyed the conversation.. julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32EBDC19.794BDF32>