From owner-cvs-all@FreeBSD.ORG Sat Mar 5 08:25:07 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31C3616A4CE; Sat, 5 Mar 2005 08:25:07 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1117C43D3F; Sat, 5 Mar 2005 08:25:07 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 0149F72DD8; Sat, 5 Mar 2005 00:25:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id F0C0E72DD4; Sat, 5 Mar 2005 00:25:06 -0800 (PST) Date: Sat, 5 Mar 2005 00:25:06 -0800 (PST) From: Doug White To: John Baldwin In-Reply-To: <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org> Message-ID: <20050305002418.A4084@carver.gumbysoft.com> References: <200503030241.j232fbCn032297@repoman.freebsd.org> <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Doug White cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Alan Cox cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 08:25:07 -0000 On Thu, 3 Mar 2005, John Baldwin wrote: > > On Mar 3, 2005, at 1:24 AM, Alan Cox wrote: > > > On Thu, Mar 03, 2005 at 02:41:37AM +0000, Doug White wrote: > >> dwhite 2005-03-03 02:41:37 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> sys/kern uipc_mbuf.c > >> Log: > >> Insert volatile cast to discourage gcc from optimizing the read > >> outside > >> of the while loop. > >> > >> Suggested by: alc > >> MFC after: 1 day > >> > >> Revision Changes Path > >> 1.144 +4 -1 src/sys/kern/uipc_mbuf.c > > > > I tend to believe that the sparc64's casa() implementation is the real > > culprit here. Specifically, I don't believe the right asm operand > > constraints are being used. If I'm correct, the addition of volatile > > here is unnecessary. Can we hold the MFC until this hypothesis is > > proven or disproven? > > Yes, it looks like it isn't clobbering "memory" which atomic operations > on other architectures do. I'll accept a patch to fix this and even try testing it. Fiddling with low level sparc64 stuff is beyond my skill level, though. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org