From owner-freebsd-current Fri Jun 15 22:58:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from technokratis.com (modemcable052.174-202-24.mtl.mc.videotron.ca [24.202.174.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AE7A37B405; Fri, 15 Jun 2001 22:57:56 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f5G5wNh00854; Sat, 16 Jun 2001 01:58:23 -0400 (EDT) (envelope-from bmilekic) Date: Sat, 16 Jun 2001 01:58:23 -0400 From: Bosko Milekic To: freebsd-current@freebsd.org Cc: jlemon@freebsd.org, terry@freebsd.org, rwatson@freebsd.org Subject: Re: New Mbuf Allocator (some graphs) Message-ID: <20010616015823.A842@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jun 15, 2001 at 11:56:05PM -0500, Jonathan Lemon wrote: > On Fri, Jun 15, 2001 at 07:44:59PM -0400, Bosko Milekic wrote: > > > > > Here are some performance results. Keep in mind that we're still under > > > > Giant. > > > > > > > > http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html > > > > > > Just for comparision, 6-way results are at: > > > > > > http://www.flugsvamp.com/~jlemon/fbsd/netpipe/ > > > > Are you sure those aren't inverted? (i.e. swap(present, mb_alloc)?) > > > > In any case, the mb_alloc code you used still has the malloc() and > > free() calls during cluster allocation and freeing and still, it looks to > > me as very comparable nonetheless. > > I've updated the page with results from running Bosko's latest > code (without the malloc/free calls). The results are at the > above URL. The performance of the new allocator on this benchmark > comes out ahead of the old one. Great. All I'm really aiming for at this time is "comparable" (i.e. not significantly worse) but I won't complain if I see "a little better" niether. With the added `weight' of having to keep track of what mbufs or clusters belong to what page (and all the associated management structures in the new allocator) for reclamation purposes, I was frankly expecting that with Giant still in place, to come out slightly under. Since we're slightly higher, it's all for the better, since the performance should only get better as Giant is unwound. I did some tests over ethernet between two dual processor machines, I've added the results to the page, and also dropped a link to your page. Thanks for the testing! > -- > Jonathan Cheers, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message