From owner-freebsd-current Fri Mar 7 6:39:36 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AE5E37B405 for ; Fri, 7 Mar 2003 06:39:35 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DC4A43F85 for ; Fri, 7 Mar 2003 06:39:34 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h27Ebam18645; Fri, 7 Mar 2003 09:37:36 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 7 Mar 2003 09:37:36 -0500 From: Bosko Milekic To: Petri Helenius Cc: freebsd-current@FreeBSD.ORG Subject: Re: mbuf cache Message-ID: <20030307093736.A18611@unixdaemons.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <001201c2e2ee$54eedfb0$932a40c1@PHE>; from pete@he.iki.fi on Wed, Mar 05, 2003 at 10:07:35AM +0200 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 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