Date: Sun, 24 Nov 2002 13:33:29 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <Pine.BSF.4.21.0211241332190.34466-100000@InterJet.elischer.org> In-Reply-To: <15841.17237.826666.653505@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. > > Drew > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211241332190.34466-100000>