svn commit: r223307 - head/sys/vm
Bruce Evans
brde at optusnet.com.au
Wed Jun 22 18:58:46 UTC 2011
On Wed, 22 Jun 2011, John Baldwin wrote:
> On Tuesday, June 21, 2011 4:58:10 pm Bruce Evans wrote:
>> On Tue, 21 Jun 2011, Bjoern A. Zeeb wrote:
>>> ...
>>> 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'.)
That is quite a bit. Perhaps the struct should be packed better so that
each char -> int expansion takes <= 3 bytes instead of >= 4. The
expansion might even be negative. It is only moderately well packed now.
> 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).
Bruce
More information about the svn-src-head
mailing list