Date: Mon, 25 Nov 2002 13:01:25 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Julian Elischer <julian@elischer.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <20021125130125.B75177@unixdaemons.com> In-Reply-To: <Pine.BSF.4.21.0211241332190.34466-100000@InterJet.elischer.org>; from julian@elischer.org on Sun, Nov 24, 2002 at 01:33:29PM -0800 References: <15841.17237.826666.653505@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0211241332190.34466-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org 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?20021125130125.B75177>