Skip site navigation (1)Skip section navigation (2)
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>