From owner-svn-src-all@FreeBSD.ORG Thu Oct 1 13:56:09 2009 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 28AF5106568D; Thu, 1 Oct 2009 13:56:09 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id C099B8FC24; Thu, 1 Oct 2009 13:56:08 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 1C4D0C4278; Thu, 1 Oct 2009 15:55:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id YeZ-jCX4Y1we; Thu, 1 Oct 2009 15:55:19 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 12CBDC4277; Thu, 1 Oct 2009 15:55:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <20091001174130.0d3bec21.stas@FreeBSD.org> Date: Thu, 1 Oct 2009 15:56:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2B51434B-9A1D-4711-9648-1A49B125C785@semihalf.com> References: <200909301326.n8UDQVB1016396@svn.freebsd.org> <3bbf2fe10910010621u72d0f692h8f9c4a783667253d@mail.gmail.com> <20091001174130.0d3bec21.stas@FreeBSD.org> To: Stanislav Sedov X-Mailer: Apple Mail (2.1076) Cc: Attilio Rao , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Robert Watson Subject: Re: svn commit: r197643 - in head/sys: kern sys 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: Thu, 01 Oct 2009 13:56:09 -0000 On 2009-10-01, at 15:41, Stanislav Sedov wrote: > On Thu, 1 Oct 2009 15:21:34 +0200 > Attilio Rao mentioned: > >> 2009/9/30 Robert Watson : >>> On Wed, 30 Sep 2009, Attilio Rao wrote: >>> >>>> When releasing a read/shared lock we need to use a write memory >>>> barrier >>>> in order to avoid, on architectures which doesn't have strong >>>> ordered >>>> writes, CPU instructions reordering. >>> >>> Hi Attilio (Fabio, et al), >>> >>> Nice catch! Are we aware of specific reported problems that can >>> be laid at >>> the feet of this bug, or was this more of a "wait a moment, >>> shouldn't there >>> be a barrier there?". Could you comment on the scope of this >>> problem across >>> architectures we support? >> >> A possible problem related to that would be MD specific and not on >> ia32/amd64 because there the barriers and simple atomics are the >> same. >> Given that sun4v suffers of serveral other problems, that MIPS has no >> SMP support, you would find it only for arm, ia64 and sparc >> eventually. Thus I'm not aware of any problem which can be >> reconducted >> to that. >> > > Actually, MIPS is going to grow SMP support really soon, and ARM cpus > do not do reordering until ARMv7 afaik. So this should not result in > any real problems on ARM too. Even past generation ARM can do out-of-order execution: see Marvell Feroceon cores which are v5 ISA compatible, although their internal microarchitecture has extended features like this. > OTOH, I suspect powerpc may be affected. I'm not sure if any of the > models > we support perform OOO, though. PowerPC is inherently OOOE. Rafal