From owner-svn-src-all@FreeBSD.ORG Wed Jun 22 03:48:39 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 B19B610657A0; Wed, 22 Jun 2011 03:48:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 143B68FC0A; Wed, 22 Jun 2011 03:48:38 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5M3kYRq085097 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2011 21:46:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4E01612F.4080007@freebsd.org> Date: Tue, 21 Jun 2011 21:46:30 -0600 Message-Id: <3B90907F-0CC4-4C2F-9386-6BF12E750F6C@bsdimp.com> References: <201106191913.p5JJDOqJ006272@svn.freebsd.org> <20110622063258.D2275@besplex.bde.org> <4E0128FF.6020804@rice.edu> <4E01612F.4080007@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 21 Jun 2011 21:46:34 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: src-committers@freebsd.org, Alan Cox , Alan Cox , svn-src-all@freebsd.org, Attilio Rao , "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 03:48:39 -0000 On Jun 21, 2011, at 9:27 PM, Julian Elischer wrote: > On 6/21/11 7:27 PM, Warner Losh wrote: >>=20 >>=20 >> On Jun 21, 2011, at 5:27 PM, Alan Cox wrote: >>=20 >>> On 06/21/2011 16:09, Attilio Rao wrote: >>>> 2011/6/21 Bruce Evans: >>>>> On Tue, 21 Jun 2011, Bjoern A. Zeeb wrote: >>>>>=20 >>>>>> On Jun 19, 2011, at 7:13 PM, Alan Cox wrote: >>>>>>=20 >>>>>> Hi Alan, >>>>>>=20 >>>>>>> Author: alc >>>>>>> Date: Sun Jun 19 19:13:24 2011 >>>>>>> New Revision: 223307 >>>>>>> URL: http://svn.freebsd.org/changeset/base/223307 >>>>>>>=20 >>>>>>> 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.) >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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: >>>>>>=20 >>>>>> 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. >>>>=20 >>>=20 >>> 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: >>>=20 >>> # 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) >>=20 >> 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!) >>=20 >> I'm guessing that this is likely just wrong. Comments? >=20 > 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) Generally, they don't. ll and lld are for 4 and 8 byte values. You're = supposed to load the word or doubleword with the instruction, mask off = the byte you want to change, change it, and then write it back with the = sc or scd insturction. That will only succeed of none of the bytes in = that word could have changed (yes, weasel words usually meaning anything = in the cache line, but really can mean anything). I know that some cores do support special instructions to do this, but = they are with extensions to the ISA... Warner=