From owner-svn-src-head@FreeBSD.ORG Sun Apr 12 15:33:24 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B061065673; Sun, 12 Apr 2009 15:33:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C1F918FC1A; Sun, 12 Apr 2009 15:33:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 65CB846B2D; Sun, 12 Apr 2009 11:33:24 -0400 (EDT) Date: Sun, 12 Apr 2009 16:33:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <30873.1239549114@critter.freebsd.dk> Message-ID: References: <30873.1239549114@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Luigi Rizzo Subject: Re: per-cpu counters (Re: svn commit: r190967 - head/sys/netinet) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 15:33:25 -0000 On Sun, 12 Apr 2009, Poul-Henning Kamp wrote: > In message , Robert > Wats on writes: > >> I have a project along these lines in progress, and will post the proposal >> to arch@ once I've finished prototyping it. In particular, it provides >> common implementations of "reset" and "report" in order to expose a single >> userspace version of the structure via sysctl. > > Please don't export them via sysctl. > > Export them via mmap(2) like we already do with the disk I/O statistics. > > That way monitoring the counters becomes a no-syscall operation. The sysctls already exist, and are used by both built-in and third-party monitoring tools. Given the 8.0 timeline and the list of other things to get done before 8.0, I'm happy to solve the per-CPU counter problem as it is necessary to do so, but I don't have time to solve the mmap'd per-CPU counter problem, as it's not necessary to do so. In the current design the per-CPU counter framework allocates the storage for the counters, so it should be easy to add that feature later. Robert N M Watson Computer Laboratory University of Cambridge