From owner-freebsd-arch Wed Dec 26 12:14: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 321D637B42A for ; Wed, 26 Dec 2001 12:14:00 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBQKLbM01442; Wed, 26 Dec 2001 12:21:37 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112262021.fBQKLbM01442@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: 64 bit counters In-reply-to: Your message of "Wed, 26 Dec 2001 13:59:02 CST." <20011226135902.O91594@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Dec 2001 12:21:37 -0800 From: Mike Smith 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 > One solution is to implement it correctly then add a knob to > turn off the syncronization for those that want speed over > correctness. They can poison their data if they so desire. This isn't good either; if you give someone a knob that can be switched from "works" to "does not work", then someone is going to set it to "does not work" and then complain. Better would be to architect a solution that works universally. You can do this with 32-bit 'working' counters which you access atomically, and maintain a 64-bit global counter that's only updated under a lock: u_int32_t wcounter u_int64_t ggounter lock_t gc_lock u_int32_t x; acquire_lock(gc_lock) x = atomic_fetch_32(wcounter) atomic_subtract_32(wcounter, x) gcounter += x release_lock(gc_lock) Do this on a periodic basis, with the interval tuned so that stats update "often enough" but without imposing too much lock load. If atomic ops on the working counters are too expensive on SMP systems, you can keep per-CPU working counters. Reaping them becomes somewhat more expensive (since you have one reap per CPU per interval) however. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message