From owner-svn-src-projects@FreeBSD.ORG Fri May 13 05:59:07 2011 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F22F106566B; Fri, 13 May 2011 05:59:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E1BF38FC12; Fri, 13 May 2011 05:59:06 +0000 (UTC) Received: from [192.168.14.163] ([24.114.252.233]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4D5rXWf061540 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 12 May 2011 23:53:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 13 May 2011 01:53:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31ABDF1E-1D1E-4DDB-B89D-D36E9B7DDC63@bsdimp.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> To: Attilio Rao X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 12 May 2011 23:53:37 -0600 (MDT) Cc: mdf@FreeBSD.org, src-committers@FreeBSD.org, Artem Belevich , Oleksandr Tymoshenko , Bruce Evans , svn-src-projects@FreeBSD.org, Warner Losh Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 05:59:07 -0000 On May 12, 2011, at 6:06 PM, Attilio Rao wrote: > 2011/5/12 : >> On Thu, May 12, 2011 at 2:12 PM, Attilio Rao = wrote: >>> 2011/5/12 Artem Belevich : >>>> On Thu, May 12, 2011 at 10:05 PM, Attilio Rao = 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=