From owner-freebsd-arch Wed Jan 16 10:31:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id BA53537B404 for ; Wed, 16 Jan 2002 10:31:35 -0800 (PST) Received: (qmail 17492 invoked from network); 16 Jan 2002 18:31:34 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jan 2002 18:31:34 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 16 Jan 2002 10:30:51 -0800 (PST) From: John Baldwin To: Michal Mertl Subject: Re: 64 bit counters again Cc: Terry Lambert , Cc: Terry Lambert , Bosko Milekic , "James E. Housley" , Thomas Hurst , arch@FreeBSD.ORG, Peter Jeremy 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 On 16-Jan-02 Michal Mertl wrote: > On Tue, 15 Jan 2002, John Baldwin wrote: > >> >> On 16-Jan-02 Peter Jeremy wrote: >> > For the read case, the reader uses something like: >> > >> > loop: movl 4(mem),%edx >> > movl (mem),%eax >> > cmpl 4(mem),%edx >> > jnz loop >> > >> > If an interrupt updates the MSW then you take another pass around the >> > loop, otherwise you always read the correct value. >> > >> > For the SMP case, you either need to use locks or you need to use >> > per-CPU counters. (And the per-CPU counters can be read by another >> > CPU using the above trick). >> >> Well, SMP on Pentium's maybe, but not on Alpha, sparc64, or ia64, all of >> which >> support OOE and looser memory models than x86, meaning that you really need >> locks unless you are going to have 386-specific code all over the place. I >> suppose you can wrap it behind an MI API but that seems like a lot of work >> for >> fairly small gain that can end up making the code uglier. >> > > This ugly hack is supposed to be required only on 32 bit platforms. For me > it's i386 (anything else with >0.1% user base?). On 64 bit platforms you > just use native operand size. > > The code, which is present in the kernel now is most probably broken (at > least on i386 compiler generates RMW). Other platforms don't _have_ a single RMW version of add for example. Most of them do a load, add, store. So are you now going to be using atomic ops for all counters? It's either that or a lock. And if you use u_int64_t for your counters, you would just need to add support for 64-bit atomic ops to the atomic API. Reading the values becomes a bit hard then though as that would require an atomic op to ensure you aren't reading a stale value. So which approach are you going to take? (They will need one of these once SMPng gets down to that level anyways.) Also, the powerpc port will be 32-bit once it gets off the ground and will likely have a fairly good userbase, as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message