Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Mar 2003 09:37:36 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Petri Helenius <pete@he.iki.fi>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: mbuf cache
Message-ID:  <20030307093736.A18611@unixdaemons.com>
In-Reply-To: <001201c2e2ee$54eedfb0$932a40c1@PHE>; from pete@he.iki.fi on Wed, Mar 05, 2003 at 10:07:35AM %2B0200
References:  <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <20030304173809.A10373@unixdaemons.com> <0e2b01c2e2a3$96fd3b40$932a40c1@PHE> <20030304182133.A10561@unixdaemons.com> <0e3701c2e2a7$aaa2b180$932a40c1@PHE> <20030304190851.A10853@unixdaemons.com> <001201c2e2ee$54eedfb0$932a40c1@PHE>

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

On Wed, Mar 05, 2003 at 10:07:35AM +0200, Petri Helenius wrote:
> I think there is nothing really special about the driver there? The mbufs
> are allocated in the driver and then freed when other parts in the kernel
> are done with the packet? The issue I´m having is that mb_free takes
> almost four times the cycles than mb_alloc for each call which does
> not seem to be right? I shouldn´t be having lock contention in mb_alloc
> because the whole thing is still under Giant, right?

  There's probably a tightloop of frees going on somewhere.  It's tough
  for me to analyze this as I cannot reproduce it.  Have you tried
  running your tests over loopback to see if the same thing happens?

  If so, and it does, can you please explain how to exactly replicate
  the test?
-- 
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?20030307093736.A18611>