From owner-svn-src-all@FreeBSD.ORG Wed Jun 22 03:27:53 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 C6B511065679; Wed, 22 Jun 2011 03:27:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9040D8FC26; Wed, 22 Jun 2011 03:27:53 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p5M3RW1L020349 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Jun 2011 20:27:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E01612F.4080007@freebsd.org> Date: Tue, 21 Jun 2011 20:27:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <201106191913.p5JJDOqJ006272@svn.freebsd.org> <20110622063258.D2275@besplex.bde.org> <4E0128FF.6020804@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:27:53 -0000 On 6/21/11 7:27 PM, Warner Losh wrote: > > On Jun 21, 2011, at 5:27 PM, Alan Cox wrote: > >> On 06/21/2011 16:09, Attilio Rao wrote: >>> 2011/6/21 Bruce Evans>> >: >>>> 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'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. >>> >> >> 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: >> >> # 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) > > 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!) > > I'm guessing that this is likely just wrong. Comments? 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) > > Warner >