From owner-freebsd-arch Wed Jan 16 13:15:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 88C4837B400 for ; Wed, 16 Jan 2002 13:15:24 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id g0GLFEle074809; Wed, 16 Jan 2002 22:15:16 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g0GLFDWT074806; Wed, 16 Jan 2002 22:15:13 +0100 (CET) Date: Wed, 16 Jan 2002 22:15:13 +0100 (CET) From: Michal Mertl To: John Baldwin Cc: Terry Lambert , Bosko Milekic , "James E. Housley" , Thomas Hurst , , Peter Jeremy Subject: Re: 64 bit counters again In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed, 16 Jan 2002, John Baldwin wrote: > > 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 My fault - I meant you wouldn't have problems with 2 partial accesses (high and low part). But you're right - it doesn't solve the problem. I made an API which makes it easy to choose whatever version of operation is required on chosen platform. No locks though. I don't know how expensive these are, but if atomicity is required and is very expensive on "strange :-)" hardware, the best way to go probably would be to have some per-cpu data and some collector kernel thread or something. Access to these counters could be also covered by my functions. But I didn't programme it nor the collecting code which would be needed then. > 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 In my patch there's also support for 64 bit atomic ops on >=i586. That's one thing which shouldn't hurt anyone. That needs review - I wasn't able to find good documentation examples for gcc inline asm constraints so I ended up mostly telling gcc exactly which register to use. > 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 With my patch it's compile time decision - the default should be probably simple 32 bit operations. That's how the counters work now (they're defined u_long so on 64 bit it's simple 64 bit operation). It should be fairly easy to make it MI. > 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. That would have to be delt with when it comes but I don't expect problems (is it English sentence ? :-) ). -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message