From owner-svn-src-all@FreeBSD.ORG Sun Apr 5 09:04:00 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 641771065674; Sun, 5 Apr 2009 09:04:00 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 2B07C8FC47; Sun, 5 Apr 2009 09:03:59 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id n3593wIe028210; Sun, 5 Apr 2009 03:03:58 -0600 Message-Id: <7F1FC303-3EFC-4182-9260-FE35C4BD9909@semihalf.com> From: Rafal Jaworowski To: Marcel Moolenaar In-Reply-To: <200904042223.n34MN3RG082677@svn.freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 5 Apr 2009 11:03:55 +0200 References: <200904042223.n34MN3RG082677@svn.freebsd.org> X-Mailer: Apple Mail (2.930.3) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r190704 - head/sys/powerpc/aim 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: Sun, 05 Apr 2009 09:04:00 -0000 On 2009-04-05, at 00:23, Marcel Moolenaar wrote: > Author: marcel > Date: Sat Apr 4 22:23:03 2009 > New Revision: 190704 > URL: http://svn.freebsd.org/changeset/base/190704 > > Log: > Perform a dummy stwcx. when we switch contexts. The context > being switched out may hold a reservation. The stwcx. will > clear the reservation. This is architecturally recommended. > > The scenario this addresses is as follows: > 1. Thread 1 performs a lwarx and as such holds a reservation. > 2. Thread 1 gets switched out (before doing the matching > stwcx.) and thread 2 is switched in. > 3. Thread 2 performs a stwcx. to the same reservation granule. > This will succeed because the processor has the reservation > even though thread 2 didn't do the lwarx. > > Note that on some processors the address given the stwcx. is > not checked. On these processors the mere condition of having > a reservation would cause the stwcx. to succeed, irrespective > of whether the addresses are the same. The dummy stwcx. is > especially important for those processors. Have you seen this false stwcx. actually succeed in some real scenarios on AIM? Were there any tangible [corruption?] effects observed without this fix? We're seeing some hang with the dual E500 under very heavy loads, but only with ULE (or we could only correlate this with ULE so far), but didn't get to really close investigation of this issue yet. I'm wondering if it's something of this sort too. Rafal