Date: Wed, 16 Jan 2002 22:15:13 +0100 (CET) From: Michal Mertl <mime@traveller.cz> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Terry Lambert <tlambert2@mindspring.com>, Bosko Milekic <bmilekic@technokratis.com>, "James E. Housley" <jeh@FreeBSD.ORG>, Thomas Hurst <tom.hurst@clara.net>, <arch@FreeBSD.ORG>, Peter Jeremy <peter.jeremy@alcatel.com.au> Subject: Re: 64 bit counters again Message-ID: <Pine.BSF.4.41.0201162158070.73630-100000@prg.traveller.cz> In-Reply-To: <XFMail.020116103051.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.41.0201162158070.73630-100000>