2011/6/24 Jayachandran C. <c.jayachand...@gmail.com>: > On Fri, Jun 24, 2011 at 1:33 AM, Alan Cox <a...@rice.edu> wrote: >> On 6/23/2011 1:30 PM, Warner Losh wrote: >>> >>> On Jun 23, 2011, at 2:17 AM, Bjoern A. Zeeb wrote: >>> >>>> On Jun 23, 2011, at 5:24 AM, Alan Cox wrote: >>>> >>>>> Author: alc >>>>> Date: Thu Jun 23 05:23:59 2011 >>>>> New Revision: 223464 >>>>> URL: http://svn.freebsd.org/changeset/base/223464 >>>>> >>>>> 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... >>> >> >> 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 will try out an implementation and see if this works on XLR, if so > this is something we can add to support.S
There is a chance we can leave all the atomic support inlined in atomic.h? When I looked into it, my opinion is that support.S part is just in the wrong place (and Warner didn't have a good explanation for it, so I don't see a problem about moving anything to atomic.h). Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"