Date: Thu, 23 Jun 2011 15:15:26 -0600 From: Warner Losh <imp@bsdimp.com> To: Alan Cox <alc@rice.edu> Cc: Alan Cox <alc@FreeBSD.org>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r223464 - head/sys/vm Message-ID: <80DB2C1D-8C66-440D-ADF3-1FBD24D4D116@bsdimp.com> In-Reply-To: <4E039C0F.10505@rice.edu> References: <201106230524.p5N5O0Rs084548@svn.freebsd.org> <31243267-5FE1-4104-9B77-4F3EAAD4523B@FreeBSD.org> <B790D7A9-CDE6-482A-BF58-686CA5FF9667@bsdimp.com> <4E039C0F.10505@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 23, 2011, at 2:03 PM, Alan Cox wrote: > On 6/23/2011 1:30 PM, Warner Losh wrote: >> On Jun 23, 2011, at 2:17 AM, Bjoern A. Zeeb wrote: >>=20 >>> On Jun 23, 2011, at 5:24 AM, Alan Cox wrote: >>>=20 >>>> Author: alc >>>> Date: Thu Jun 23 05:23:59 2011 >>>> New Revision: 223464 >>>> URL: http://svn.freebsd.org/changeset/base/223464 >>>>=20 >>>> Log: >>>> Revert to using the page queues lock in vm_page_clear_dirty_mask() = on >>>> MIPS. (At present, although atomic_clear_char() is defined by = atomic.h >>>> on MIPS, it is not actually implemented by support.S.) >>> Thanks, >>> and good catch on the atomics even if not planned, just in time for = 9.0:) >> Yea, there's some work there to fix them... Not sure we can even fix = some of them atomically... >>=20 >=20 > I'm not sure that I understand what you mean by the second statement. = Can you elaborate? The 8- and 16-bit operations should be no less = "atomic" than the 32- and 64-bit operations. In general, regardless of = the size of the operation, the "sc" instruction may fail and the whole = operation has to be restarted if another processor (or I/O device) = performs a concurrent, cache coherent store to the same location (or = even cache line) as the "ll" and "sc" instructions are operating on. On = the other hand, if the "sc" instruction succeeds, whether you used it to = change all of the 32 bits or just 8 of the 32 bits, it should appear as = an atomic change to any other processor. I was thinking of the unaligned 16-bit case. Properly aligned I suppose = is a requirement, so I retract my statement: those are easy to = implement. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80DB2C1D-8C66-440D-ADF3-1FBD24D4D116>