svn commit: r223307 - head/sys/vm

[Julian Elischer]

On 6/21/11 7:27 PM, Warner Losh wrote:
>
> On Jun 21, 2011, at 5:27 PM, Alan Cox wrote:
>
>> On 06/21/2011 16:09, Attilio Rao wrote:
>>> 2011/6/21 Bruce Evans<brde at optusnet.com.au 
>>> <mailto:brde at optusnet.com.au>>:
>>>> On Tue, 21 Jun 2011, Bjoern A. Zeeb wrote:
>>>>
>>>>> On Jun 19, 2011, at 7:13 PM, Alan Cox wrote:
>>>>>
>>>>> Hi Alan,
>>>>>
>>>>>> Author: alc
>>>>>> Date: Sun Jun 19 19:13:24 2011
>>>>>> New Revision: 223307
>>>>>> URL: http://svn.freebsd.org/changeset/base/223307
>>>>>>
>>>>>> Log:
>>>>>>  Precisely document the synchronization rules for the page's 
>>>>>> dirty field.
>>>>>>  (Saying that the lock on the object that the page belongs to 
>>>>>> must be
>>>>>> held
>>>>>>  only represents one aspect of the rules.)
>>>>>>
>>>>>>  Eliminate the use of the page queues lock for atomically 
>>>>>> performing
>>>>>> read-
>>>>>>  modify-write operations on the dirty field when the underlying
>>>>>> architecture
>>>>>>  supports atomic operations on char and short types.
>>>>>>
>>>>>>  Document the fact that 32KB pages aren't really supported.
>>>>> contrary to the tinderbox I'd like to point out that all mips 
>>>>> kernels
>>>>> built by universe are broken with a SVN HEAD from earlier today. 
>>>>>  Could you
>>>>> please check and see if you can fix it?  The errors I get are:
>>>>>
>>>>> vm_page.o: In function `vm_page_clear_dirty':
>>>>> /sys/vm/vm_page.c:(.text+0x18d0): undefined reference to 
>>>>> `atomic_clear_8'
>>>>> /sys/vm/vm_page.c:(.text+0x18d0): relocation truncated to fit: 
>>>>> R_MIPS_26
>>>>> against `atomic_clear_8'
>>>>> vm_page.o: In function `vm_page_set_validclean':
>>>>> /sys/vm/vm_page.c:(.text+0x38f0): undefined reference to 
>>>>> `atomic_clear_8'
>>>>> /sys/vm/vm_page.c:(.text+0x38f0): relocation truncated to fit: 
>>>>> R_MIPS_26
>>>>> against `atomic_clear_8'
>>>> Atomic types shorter than int cannot be used in MI code, since 
>>>> they might
>>>> not exist.  Apparently they don't exist on mips.  jake@ fixed all 
>>>> their
>>>> old uses for sparc4 in ~Y2K.
>>> I'm sure they do, they exist in support.S though and may not have the
>>> _8 form (they may just have the _char version). I may look at the code
>>> again to be sure.
>>>
>>
>> It appears that while mips/include/atomic.h declares the existence 
>> of atomic_clear_8, mips/mips/support.S doesn't implement it.  In 
>> other words, only support for int's and short's is currently 
>> implemented, not char's:
>>
>> # grep atomic_clear mips/mips/support.S
>> * atomic_clear_32(u_int32_t *a, u_int32_t b)
>> LEAF(atomic_clear_32)
>> END(atomic_clear_32)
>> * atomic_clear_16(u_int16_t *a, u_int16_t b)
>> LEAF(atomic_clear_16)
>> END(atomic_clear_16)
>
> The current crop of atomic*16 and atomic*8 functions have the 
> restriction that the address must be 32-bit aligned (and it forces 
> this by aligning to 32-bits silently and then operates on the low 8 
> or 16 bits in that word!)
>
> I'm guessing that this is likely just wrong.  Comments?

I'm guessing it depends on whether the hardware supports atomic 
sub-wordline accesses.
(mind you it's getting really hard to work out what a wordline means 
these days)

>
> Warner
>