From owner-freebsd-arch@FreeBSD.ORG Tue Dec 15 09:50:14 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB671065670 for ; Tue, 15 Dec 2009 09:50:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id D00F68FC20 for ; Tue, 15 Dec 2009 09:50:13 +0000 (UTC) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 10:38:07 +0100 Date: Tue, 15 Dec 2009 10:38:04 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: arch@freebsd.org Message-ID: <20091215103759.P97203@beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Dec 2009 09:38:07.0697 (UTC) FILETIME=[4EE2C410:01CA7D6A] Cc: Subject: network statistics in SMP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 09:50:14 -0000 Hi all, I'm working on our network statistics (in the context of SNMP) and wonder, to what extend we want them to be correct. I've re-read part of the past discussions about 64-bit counters on 32-bit archs and got the impression, that there are users that would like to have almost correct statistics (for accounting, for example). If this is the case I wonder whether the way we do the statistics today is correct. Basically all statistics are incremented or added to simply by a += b oder a++. As I understand, this worked fine in the old days, where you had spl*() calls at the right places. Nowadays when everything is SMP shouldn't we use at least atomic operations for this? Also I read that on architectures where cache coherency is not implemented in hardware even this does not help (I found a mail from jhb why for the mutex implementation this is not a problem, but I don't understand what to do for the += and ++ operations). I failed to find a way, though, to influence the caching policy (is there a function one can call to change the policy?). Any opinions? harti