From owner-svn-src-all@FreeBSD.ORG Wed Jun 22 13:53:12 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2641D106566C; Wed, 22 Jun 2011 13:53:12 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE9F8FC1A; Wed, 22 Jun 2011 13:53:11 +0000 (UTC) Received: by gxk19 with SMTP id 19so854338gxk.17 for ; Wed, 22 Jun 2011 06:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7T9ZxVhZrKhXcUzceRQk8X3lNvbf9FLNLqrqlTQ36Xs=; b=JwMtRqzbcKVuMTd61s7PsuU6F3l2XSwFzgaSyac2M70Jkn5OoL3Nd7weVZ3rpN2Jan VUGNtbByh5WH8h40wSxsFYZ+3R2N8/hI0z9j7jMkX+8UcLTvfcmqB+Uk+71pwuFYjuAa Yv5kX+xGiPV6n1F0OWheaKfMjLDPJrPfMfpHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=aNNiALRGHJZrs1u//ZJ09//jWNzToLZL654AF00SfSzm9vdsbabSRDJ6yn01i8adkX o/TTJGUfkDVhy1Mj8nBlkBY0x2FkFqWzEyJ5TZlnt/M4J4TvGuCYDrc39cpoI6Mro4Ni STI1RaXBo5WP8SFsGKoNsImAP2ISq7yRz+hTg= MIME-Version: 1.0 Received: by 10.236.111.20 with SMTP id v20mr1189923yhg.423.1308750790550; Wed, 22 Jun 2011 06:53:10 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.110.141 with HTTP; Wed, 22 Jun 2011 06:53:10 -0700 (PDT) In-Reply-To: <201106220948.02421.jhb@freebsd.org> References: <201106191913.p5JJDOqJ006272@svn.freebsd.org> <20110622063258.D2275@besplex.bde.org> <201106220948.02421.jhb@freebsd.org> Date: Wed, 22 Jun 2011 15:53:10 +0200 X-Google-Sender-Auth: oXsgX_O3FNx9NMzsRaHEeE3iCbA Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: src-committers@freebsd.org, Alan Cox , svn-src-all@freebsd.org, "Bjoern A. Zeeb" , Bruce Evans , svn-src-head@freebsd.org Subject: Re: svn commit: r223307 - head/sys/vm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:53:12 -0000 2011/6/22 John Baldwin : > 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: >> >> =C2=A0Precisely document the synchronization rules for the page's dir= ty field. >> >> =C2=A0(Saying that the lock on the object that the page belongs to mu= st be held >> >> =C2=A0only represents one aspect of the rules.) >> >> >> >> =C2=A0Eliminate the use of the page queues lock for atomically perfor= ming read- >> >> =C2=A0modify-write operations on the dirty field when the underlying = architecture >> >> =C2=A0supports atomic operations on char and short types. >> >> >> >> =C2=A0Document 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. =C2=A0Coul= d > you please check and see if you can fix it? =C2=A0The 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 migh= t >> not exist. =C2=A0Apparently they don't exist on mips. =C2=A0jake@ fixed = all their >> old uses for sparc4 in ~Y2K. > > I agree. =C2=A0Is 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 12= 8. > > 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 o= f > RAM, so around 0.18% of RAM would be used on both platforms (presumably t= he > usage would be similar on other platforms as well). =C2=A0At 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 --=20 Peace can only be achieved by understanding - A. Einstein