Date: Fri, 13 May 2011 01:53:31 -0400 From: Warner Losh <imp@bsdimp.com> To: Attilio Rao <attilio@FreeBSD.org> Cc: mdf@FreeBSD.org, src-committers@FreeBSD.org, Artem Belevich <art@FreeBSD.org>, Oleksandr Tymoshenko <gonzo@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-projects@FreeBSD.org, Warner Losh <imp@FreeBSD.org> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <31ABDF1E-1D1E-4DDB-B89D-D36E9B7DDC63@bsdimp.com> In-Reply-To: <BANLkTimkW-S%2BmGrwPMYdHTqZ%2BhoYA=xxeA@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <BANLkTi=e7GtBM-PTq9yJHSLRoaOWh62AeA@mail.gmail.com> <BANLkTiktwEvRktZrGOqKKB2iSB99a3Jw=g@mail.gmail.com> <BANLkTik17r-XampEdO%2BsQ7aMOL_SDyhG=g@mail.gmail.com> <BANLkTinaWDcaiZiB3G5Szoaho1jVSeniMA@mail.gmail.com> <BANLkTimj3ohmvACmvcPa3yrdsUj=4D2V3Q@mail.gmail.com> <BANLkTikSgEXZz8vjj7kuyeWQE_oKqzB8ug@mail.gmail.com> <BANLkTinHGpL5tC3-5jOPUq6bJ2Ks7j_Dww@mail.gmail.com> <BANLkTi=DOD9p-YUMm33D5ZShTjS_Q1hEvg@mail.gmail.com> <BANLkTikj%2Bszgd%2BptzD6y%2BofPs%2B8bR7Z8ew@mail.gmail.com> <BANLkTi=hB=ytsGFD8NbG7q56qTQJjroPHg@mail.gmail.com> <BANLkTimkW-S%2BmGrwPMYdHTqZ%2BhoYA=xxeA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 12, 2011, at 6:06 PM, Attilio Rao wrote: > 2011/5/12 <mdf@freebsd.org>: >> On Thu, May 12, 2011 at 2:12 PM, Attilio Rao <attilio@freebsd.org> = wrote: >>> 2011/5/12 Artem Belevich <art@freebsd.org>: >>>> On Thu, May 12, 2011 at 10:05 PM, Attilio Rao <attilio@freebsd.org> = wrote: >>>>> I spoke in person with Artem and in the end I just decided to make = the >>>>> smallest possible subset of changes to fix the _long on 32 bits = and >>>>> then "completed" (as some of them already exist today) the macro >>>>> converting the arguments to u_int stuff: >>>>> http://www.freebsd.org/~attilio/largeSMP/mips-atomic2.diff >>>>=20 >>>> Attilio, >>>>=20 >>>> Let's get back for a second to the original issue you had that = propted >>>> you to do atomic ops changes. >>>> If I understand you correctly, your code was passing cpuset_t* as = an >>>> argument to atomic_something_long and that caused compiler to = complain >>>> that cpuset_t* is not uint32_t*. >>>>=20 >>>> Could you post definition of cpuset_t ? >>>>=20 >>>> It's possible that compiler was actually correct. For instance, >>>> compiler would be right to complain if cpuset_t is a packed = structure, >>>> even if that structure is made of a single uint32_t field. >>>=20 >>> It doesn't do the atomic of cpuset_t, it does atomic of members of >>> cpuset_t which are actually long. >>=20 >> Isn't this an argument for making it an array of u_int, even though >> it's marginally pessimal on amd64 and other 64-bit arches? There is >> guaranteed support for a int-sized (or perhaps 32-bit sized) atomic >> op. >>=20 >=20 > There is also guaratees for long-sized atomic operations. I'm not sure > what atomic(9) says, but the truth is that long on FreeBSD always > matches word boundry, so there is no problem (Bruce thinks that long > actually had to be double the size of words, hence the theoretically > possible difficulties for atomic operation, but actually that never > was the case on FreeBSD). If we can't pass a long-sized operand to the atomic_long operations, = then I'd say that's a bug. I think that the current ABI zoo on MIPS may mean that it makes sense to = define atomic_foo_32, atomic_foo_64, etc and then define atomic_long in = terms of them, such that type-safety is ensured. Since the _32/_64 = functions are defined in .S files, adding aliases based on ABI is easy = and we can just have the right prototypes in the mips atomic.h. While a = little gross in some sense, we know that we can audit things such that = it will be correct, and also optimal. This is, after all, low level = code and that code often calls for tricks to get optimal performance. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31ABDF1E-1D1E-4DDB-B89D-D36E9B7DDC63>