svn commit: r223307 - head/sys/vm

[Attilio Rao]

2011/6/22 John Baldwin <jhb at freebsd.org>:
> On Tuesday, June 21, 2011 4:58:10 pm Bruce Evans wrote:
>> 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 agree.  Is there any harm in having the 'dirty' and 'valid' fields in
> vm_page always be at least of size 'int'?
>
> In the case of amd64, vm_page would change from a size of 120 bytes to 128.
>
> On i386 I think you'd end up changing the size from 68 to 76.
>
> (Using an int results in alignment padding after 'busy'.)
>
> Hmm, that's around 120k of extra vm_page_t space for a machine with 64M of
> RAM, so around 0.18% of RAM would be used on both platforms (presumably the
> usage would be similar on other platforms as well).  At 24 GB of RAM, the
> extra space is just under 0.20% of RAM (48M).

I think that there is a bit of misunderstanding here.

The idea here is to use just the atomic 8bits for the architectures
that support it and otherwise use the vm_page_queue_lock.
Anyway, as not all the architectures have this implementation, rather
than replicate a lot of MD code to be used in MI, Alan just went with
an explicit stub, where necessary.

The real bug I see here is that we thought mips was supporting _8
atomic ops while it doesn't seem to be the case (sorry for being lazy
on checking, but I nearly have 0 time).

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein