Date: Mon, 9 May 2011 02:25:25 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@FreeBSD.org> Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Nathan Whitehorn <nwhitehorn@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <20110509021804.D2381@besplex.bde.org> In-Reply-To: <BANLkTi=6N_bjB2Mf5wffXRRscbAT4%2BMcGQ@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com> <4DC6ACE6.2090609@freebsd.org> <BANLkTinD78M6zK6Sjpr_VROe-cJpAZbHzQ@mail.gmail.com> <4DC6AE27.3060803@freebsd.org> <BANLkTi=6N_bjB2Mf5wffXRRscbAT4%2BMcGQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 May 2011, Attilio Rao wrote: > 2011/5/8 Nathan Whitehorn <nwhitehorn@freebsd.org>: >> On 05/08/11 09:49, Attilio Rao wrote: >>> >>> 2011/5/8 Nathan Whitehorn<nwhitehorn@freebsd.org>: >>>> >>>> On 05/08/11 09:44, Attilio Rao wrote: >>>>> I want to comment specifically on this. >>>>> I think you are right and that over time our kernel policy on atomic >>>>> has got very flakey. >>>>> My personal idea is that MI part should support only this: >>>>> - _int version >>>>> - _32 bit version >>>>> - _ptr version >>>>> >>>>> and the common sense also mandates it could support easilly: >>>>> - _long version >>>> >>>> One thing I'd like to point out about your patch (which Andreas already >>>> mentioned) is that it disconnects atomic_*_long operations on 32-bit PPC, >>>> making them undefined. Since long is also a 32-bit type like int on these >>>> systems, the 32-bit kernel does in fact support this. I thought that the macro hackery for that was still there (but moved). Otherwise standard kernel files won't compile. >>>>> The following should just be used in specific MD code or be totally >>>>> unsupported: >>>>> - _char, _short, _8 bit, _16 bit versions >>>>> >>>>> The following should just be used in MD code: >>>>> - _64 bit version >>>> >>>> One other unrelated comment here: ZFS requires 64-bit atomics, so we >>>> already >>>> don't have this situation, sadly. >>> >>> I'm wondering how is that supposed to work on 32 bit stuff then. >>> I really don't want to see 32 bits arch having 64-bits faking atomics >>> as the only right way to do that is with some sort of interlocking and >>> that is not really what we want about the concept of 'atomic' (a >>> lockless and fast primitive). >> >> The answer is that it mostly doesn't. On i386, it uses cmp8xchg. On all >> other 32-bit systems (ARM/MIPS/PowerPC), it works only with a giant mutex >> that covers atomic operations. i386 has only used cmpxchg8b for a few weeks, and only uses it for load/ store. But a non-giant mutex should work OK (just like it does for a data structure much larger than 32 or 64 bits). The mutex has to cover _all_ accesses to the parts of the struct locked by it, which is sometimes not so easy. > This type of code is still ok, I'd say, because it handle platform > size in different ways (it is true it is MI code, but it just uses the > _64 bit operations only for 64 bit architectures, and locking for the > other, if I got it right). Probably much slower for the non-64 arches if it is just hacked on. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509021804.D2381>