From owner-svn-src-all@FreeBSD.ORG Mon Jun 4 14:05:26 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E644106564A; Mon, 4 Jun 2012 14:05:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 425C68FC14; Mon, 4 Jun 2012 14:05:25 +0000 (UTC) Received: by laai10 with SMTP id i10so3816877laa.13 for ; Mon, 04 Jun 2012 07:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+A5L7pd1wMBvAxqm7YAh0KmSMcw8+4BidHzM8puCTFg=; b=woBJXglRH5zXmjIhVQO8XZKU2BHrsURcB2aUon7HCm2A4uwqLjiEpQvC/4WssSWTaj IIbR3bBcxau2/A3lQD15bkdmrWi51y854uAtVnMcf9VmQ1JmVKBP85mJX/ureWoPkhND 7aXXNtr3ktRWfSHxR2muQA9j803ZaA/Tyck8VI53hpEAos/VdQtDg+6sazNhie8hp9SJ N1pfpGusRl8Z6adcDgla9cjkuJK7rIQBk1dhldLwF963czmclbzcvyGG0x0Z2SNSo9Ey bduAXy7NeS/GEdLCVtJnVLfnYUPMHUkJdxt7Q7UHsRSZiv6eZRaMDOk3RJPdRsFgQRgK yWLQ== MIME-Version: 1.0 Received: by 10.112.103.194 with SMTP id fy2mr6215541lbb.64.1338818337361; Mon, 04 Jun 2012 06:58:57 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Mon, 4 Jun 2012 06:58:57 -0700 (PDT) In-Reply-To: <20120604125050.GA85127@deviant.kiev.zoral.com.ua> References: <201206021810.q52IAGZA004238@svn.freebsd.org> <4FCC873B.90104@freebsd.org> <20120604125050.GA85127@deviant.kiev.zoral.com.ua> Date: Mon, 4 Jun 2012 14:58:57 +0100 X-Google-Sender-Auth: y1ZYnXydrcaQp7JLU5eKqVew7dY Message-ID: From: Attilio Rao To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, Tijl Coosemans , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r236456 - in head/sys: amd64/include i386/include X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:05:26 -0000 2012/6/4 Konstantin Belousov : > On Mon, Jun 04, 2012 at 12:00:27PM +0200, Tijl Coosemans wrote: >> On 02-06-2012 20:10, Konstantin Belousov wrote: >> > Author: kib >> > Date: Sat Jun =C2=A02 18:10:16 2012 >> > New Revision: 236456 >> > URL: http://svn.freebsd.org/changeset/base/236456 >> > >> > Log: >> > =C2=A0 Use plain store for atomic_store_rel on x86, instead of implici= tly >> > =C2=A0 locked xchg instruction. =C2=A0IA32 memory model guarantees tha= t store has >> > =C2=A0 release semantic, since stores cannot pass loads or stores. >> >> They can pass non-temporal stores can't they? > Sure. But (our) barriers only work for WB memory accesses, in respect to = other > WB memory accesses. > > The atomic(9) contains not quite explicit mention of the requirement, > for ia32 and more direct notion for ia64. It could probably be reworded t= o > mention memory access type explicitely for ia32 too. I don't think this is right. What if I want to use NTI in a block of code locked? What if I want to use CLFLUSH? I simply cannot do that now because of the reordering requirement. Also, there is the more worrisome case of the string operations. If gcc/clang optimize the code in order to do string operations between locked path, this is not valid anymore as they can be reordered against the _rel() barrier. However, we should consider atomic(9) as a script for MI requirement of our locking primitives among the architectures. Right now too many things live on assumptions of people doing patches (like this case) rather than actually working on a common policy of what we can easilly support and what we can't. I also wondered often if we should use *fence on architectures supporting them, by default, because of the possibility to use FPU now (which wasn't present back in the day) and thus we cannot really guarantee memory ordering over stores of memory areas bigger than a quad-word. If we don't want to add the burden, we should explicitely mention that in atomic(9) or any other place. Definitively: I think this patch violates some edge cases. Please back it o= ut. Attilio --=20 Peace can only be achieved by understanding - A. Einstein