Date: Sun, 5 Apr 2009 11:03:55 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Marcel Moolenaar <marcel@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r190704 - head/sys/powerpc/aim Message-ID: <7F1FC303-3EFC-4182-9260-FE35C4BD9909@semihalf.com> In-Reply-To: <200904042223.n34MN3RG082677@svn.freebsd.org> References: <200904042223.n34MN3RG082677@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7F1FC303-3EFC-4182-9260-FE35C4BD9909>