Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Feb 2003 07:24:20 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: mb_alloc cache balancer / garbage collector
Message-ID:  <20030217072420.A64237@unixdaemons.com>
In-Reply-To: <20030217052758.E85957-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Mon, Feb 17, 2003 at 05:29:18AM -0500
References:  <20030216213552.A63109@unixdaemons.com> <20030217052758.E85957-100000@mail.chesapeake.net>

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

On Mon, Feb 17, 2003 at 05:29:18AM -0500, Jeff Roberson wrote:
> 
> On Sun, 16 Feb 2003, Bosko Milekic wrote:
> 
> >
> >   I've finally gotten around to implementing the cache balancer/garbage
> >   collector for the mbuf allocator.  Actually, it's been sitting in a
> >   local tree for a while but I finally got one of my -CURRENT machines
> >   back up and was able to debug it.
> >
> 
> Bosko, this is great stuff.  This leads me to wonder though, are we ever
> going to unify mb alloc and uma?  It seems that it would make sense to do
> so.  If the performance is not as good with UMA then it may make sense to
> keep mb_alloc.  Especially now that it can reclaim memory.  Have you
> looked at catching the low memory callback to drain your caches?

  I looked at unifying the allocator but there are several problems that
  make doing it pretty tough.  One of these is the optimizations that we
  perform in mb_alloc.  Notably, mbufs and mbuf clusters share the same
  cache lock.  Also, I have routines that are able to allocate an mbuf
  and a cluster in one shot in one function call without dropping the
  cache lock in between.  Similarily, m_getm() can allocate a large
  number of mbufs and clusters in one shot without - in the best and
  hopefully common case - dropping any cache lock in between.  Although
  UMA is really good, from looking at it I doubt that I would be able to
  make these kinds of optimizations without ripping into/outof it pretty
  hard.

> Cheers,
> Jeff

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

"If we open a quarrel between the past and the present, we shall
 find that we have lost the future."

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




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