Date: Tue, 08 May 2001 08:35:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Bosko Milekic <bmilekic@technokratis.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Mbuf slab [new allocator] Message-ID: <3AF8123F.632C02E6@mindspring.com> References: <20010503195904.A53281@technokratis.com> <200105051833.f45IXiW49096@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > Bosko Milekic wrote: > : Anyone interested in the mbuf subsystem code should > : probably read this. Others may still read it, but it > : is somewhat longer than your average Email, so consider > : this a warning. :-) Also, although I tried my best to > : cover most issues here, feel free to let me know if I > : should clarify some points. > : > : Not so long ago, as I'm sure some of you remember, > : Alfred committed a patch > : ... > > Sounds good. You know the motto - first make it work, > then make it fast. SLAB allocators are inherently pessimal for symmetry and kernel preemption, which is to say, this change would be inherently bad for SMP. I also personally think SLAB allocators are _not_ the way to go in the long run (or even in the short run). I would point you guys to: UNIX Internals: The New Frontiers Uresh Vahalia Chapter 12 Specifically, I suggest looking at the Dynix Allocator; the author likes the SLAB allocators, and when I was reviewing the book for Prentice Hall prior to its publication, we differed significantly on some aspects of Chapter 12. The Dynix allocator is still the best bet for optimal concurrency; a combination of the Dynaix allocator and a zone allocator would probably be the best we could hope for in the near term, without a total rewrite taking cache coloring into account. Note that the _primary factor_, IMO, limiting the number of processors usable by SVR4 prior to degrading unacceptably, is the use of a SLAB allocator, which places all processors into the same contention zone. If you guys _insist_ on going to a SLAB allocator, _at least_ do it right -- one of the few benefits of a SLAB allocator is the ability to perform allocations at interrupt level, if it is correctly implemented. -- Terry 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?3AF8123F.632C02E6>