2011/6/22 John Baldwin <j...@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 _______________________________________________ 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"
