On Sun, Nov 24, 2002 at 01:33:29PM -0800, Julian Elischer wrote: > > > On Sun, 24 Nov 2002, Andrew Gallatin wrote: > > > > > If we're going to nitpick the mbuf system, a much, much worse problem > > is that you cannot allocate an mbuf chain w/o holding Giant, which > > stems from the mbuf system eventually calling kmem_malloc(). This > > effectively prevents any network driver from being giant-free. When > > mbufs are low, mb_alloc() calls mb_pop_cont(). This, in turn, calls > > kmem_malloc() which requires Giant... > > > > The mbuf system calls malloc in other ways too. The first time you > > use a cluster, m_ext.ext_ref_cnt is malloc()'ed, and malloc is called > > when the mbuf map is expanded... I assume malloc will eventually > > call kmem_malloc(), leading to the same locking problems. > > > > I know that both tru64 and aix just malloc their mbufs. > > I think we tied that and went back to a separate allocator, but I have > no idea why.. maybe someone else can enlighten me..
As I mentionned in a previous Email, it all has to do with what were considered to be the requirements of network buffer allocations and optimisations in that respect. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
