svn commit: r223464 - head/sys/vm

Warner Losh imp at bsdimp.com
Thu Jun 23 21:18:36 UTC 2011


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:
>> 
>>> 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 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


More information about the svn-src-all mailing list