Date: Wed, 16 Jan 2002 10:30:51 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Michal Mertl <mime@traveller.cz> 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: <XFMail.020116103051.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.41.0201160843480.96117-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020116103051.jhb>