Date: Thu, 3 Mar 2005 08:07:33 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Alan Cox <alc@cs.rice.edu> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <34c3d5c3060ce1ea1be35d9be1198902@FreeBSD.org> In-Reply-To: <20050303062458.GA15192@cs.rice.edu> References: <200503030241.j232fbCn032297@repoman.freebsd.org> <20050303062458.GA15192@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34c3d5c3060ce1ea1be35d9be1198902>