From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 16 10:23:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F1FF16A4CF for ; Wed, 16 Feb 2005 10:23:00 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C708E43D41 for ; Wed, 16 Feb 2005 10:22:59 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j1GAMoDS026200; Wed, 16 Feb 2005 02:22:54 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200502161022.j1GAMoDS026200@gw.catspoiler.org> Date: Wed, 16 Feb 2005 02:22:50 -0800 (PST) From: Don Lewis To: max@love2party.net In-Reply-To: <200502151655.09800.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org cc: borjamar@sarenet.es Subject: Re: MBUF statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 10:23:00 -0000 On 15 Feb, Max Laier wrote: > On Tuesday 15 February 2005 12:38, Borja Marcos wrote: >> Hello, >> >> Looking at the mbuf statistics available in FreeBSD 4 and FreeBSD 5 I >> can see that the statistics available in FreeBSD 5 are, surprisingly, >> much less comprehensive. Is there any other place where I can find out >> how many mbuf requests have been done, how many of them have waited, >> how many have failed, etc? > > I use "$vmstat -z | grep Mbuf". The netstat -m output is broken, because > fixing this would impose an additional atomic operation on each alloc/free > which is a real performance killer. Why not maintain the statistics on a per-CPU basis, and sum up the per-CPU statistics in the sysctl handler? The handler might not get an exact snapshot, but that shouldn't matter. In the case of counters that are wider than 32 bits, it might be necessary to break the counters up into chunks that can be incremented atomically, and grab a lock when the least significant chunk overflows.