Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jul 2002 16:42:25 -0400
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Luigi Rizzo <rizzo@icir.org>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: mbuf external buffer reference counters
Message-ID:  <20020711164225.A18852@unixdaemons.com>
In-Reply-To: <20020711133802.A31827@iguana.icir.org>; from rizzo@icir.org on Thu, Jul 11, 2002 at 01:38:02PM -0700
References:  <20020711162026.A18717@unixdaemons.com> <20020711133802.A31827@iguana.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, Jul 11, 2002 at 01:38:02PM -0700, Luigi Rizzo wrote:
> Hi,
> 
> certainly removing the malloc will improve performance a lot.
> 
> As I already mentioned to Bosko, in principle the available area
> in ext.buffers is irrelevant, and i do not believe this will break
> anything (and if it does, it will be easy to fix in the kernel),
> but some applications might decide to do writes in multiple of 1K
> and trimming away the refcount area might easily result in suboptimal
> allocation of storage within the kernel.

  Can you elaborate on the sub-optimal performance comment with,
  perhaps, an example?  I'm sorry but I'm sometimes slow to understand
  these days (lack of sleep).  Just recently, I was wondering why a
  10megabit card was being outperformed by a 100megabit card, where the
  first was plugged into a 10/100 dual speed hub. D'oh. :-(

> I'd probably try to use the same technique as -stable (i.e. have
> a separate array for all refcounts), if that is not too bad
> from other points of view.

  The problem with this approach is that I'm probably going to be
  allocating jumbo bufs from the same map, in which case you would have
  huge `gaps' in your address <-> ref. count location map and, as a
  result, a lot of wastage.  Plus the jumbo bufs will actually store the
  counter at the end of themselves, so it would be nice if clusters did
  the same.  I don't mind either way, but it's the first reason that
  compells me to stash them at the end of the cluster.

> 	cheers
> 	luigi
> 
> On Thu, Jul 11, 2002 at 04:20:26PM -0400, Bosko Milekic wrote:
> > 
> > Hi,
> > 
> >   Right now, in -CURRENT, there is this hack that I introduced that
> >   basically just allocates a ref. counter for external buffers attached
> >   to mbufs with malloc(9).  What this means is that if you do something
> >   like allocate an mbuf and then a cluster, there's a malloc() call that
> >   is made to allocate a small (usually 4-byte) reference counter for it.
> > 
> >   That sucks, and even -STABLE doesn't do this. I changed it this way
> >   a long time ago for simplicity's sake and since then I've been meaning
> >   to do something better here.  The idea was, for mbuf CLUSTERS, to
> >   stash the counter at the end of the 2K buffer area, and to make
> >   MCLBYTES = 2048 - sizeof(refcount), which should be more than enough,
> >   theoretically, for all cluster users.  This is by far the easiest
> >   solution (I had it implemented about 10 months ago) and it worked
> >   great.
> > 
> >   The purpose of this Email is to find out if anyone has concrete
> >   information on why this wouldn't work (if they think it wouldn't).
> >   So, if someone has an example of some broken code somewhere that
> >   wouldn't like this, please point it out to me now before I go off and
> >   do this again and commit it.
> > 
> > Thanks,
> > -- 
> > Bosko Milekic
> > bmilekic@unixdaemons.com
> > bmilekic@FreeBSD.org

  Thanks for your feedback.

-- 
Bosko Milekic
bmilekic@unixdaemons.com
bmilekic@FreeBSD.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020711164225.A18852>