From owner-freebsd-arch Wed Jan 16 12: 8: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id B7AE737B404; Wed, 16 Jan 2002 12:07:52 -0800 (PST) Received: from pool0454.cvx21-bradley.dialup.earthlink.net ([209.179.193.199] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16QwLX-0004Zq-00; Wed, 16 Jan 2002 12:07:43 -0800 Message-ID: <3C45DD8C.E3C3414E@mindspring.com> Date: Wed, 16 Jan 2002 12:07:40 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: John Baldwin , arch@FreeBSD.org, Thomas Hurst , "James E. Housley" , Bosko Milekic , Michal Mertl Subject: Re: 64 bit counters again References: <20020116120611.A72285@gsmx07.alcatel.com.au> <20020116161251.E72285@gsmx07.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Jeremy wrote: > I think I'll retract my suggestion that it's possible to read the > counters on any CPU without locking :-). > > Locking per-CPU counters defeats most of the justification for having > per-CPU counters in the first place. (There is still some advantage - > the counters hopefully stay in the local CPU cache instead of > continually jumping between caches). This shouldn't be a problem, if the global total counter is a real total and not an incremental total, since reading these values is not a problem, only writing them, even if your cache coherency is only MEI, instead of MESI. Statistics are only ever snapshots, anyway. > How about the following: Have a per-CPU thread to read the per-CPU > counters and update them into common counters. This could be done either > by having the counter read operation schedule a read on each CPU and > then returning the total, or having a "counter update" thread that runs > in each CPU every (say) second [with a degree of time skew] and > does locked updates into a common central counter. Complicated; I think the cure is worse than the disease; I'm still very fond (if one *must* have 64 bit counters) of letting people build kernels with 64 bit counters on 32 bit processors, but leaving them 32 bit by default on those platforms. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message