Date: Sat, 5 Mar 2005 00:25:06 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <20050305002418.A4084@carver.gumbysoft.com> In-Reply-To: <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org> References: <200503030241.j232fbCn032297@repoman.freebsd.org> <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050305002418.A4084>