From owner-svn-src-all@FreeBSD.ORG Wed Jun 22 09:26:33 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 7788C10656B1; Wed, 22 Jun 2011 09:26:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id D63B48FC14; Wed, 22 Jun 2011 09:26:32 +0000 (UTC) Received: by yic13 with SMTP id 13so328921yic.13 for ; Wed, 22 Jun 2011 02:26:32 -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=bhOb7Nxr/QRKmFz2Viv/4izarL7aaeAcEYCcSixx6Ow=; b=wNYd9C2yfvbS6jxgxkgN9TTQR6+i58h+DuR9B8tkaV94NfcACGl2bYPzkgpz3xPAp1 w0uolxd84/MzUTvHGQj7kkHRGI/NCEfSkvyj8vVssbyOFBWGdFMz0YisNrz1wFvJncWb RC19mS8neTOPyscJC1JZtmOQe1z1hr2F63ILw= 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=NqYIrQWv2Pnj659FUvyZ+hIZN1R2AK+SOCBHlvSg7gQNhFbdAslHuM8NMftDwY35Px zr6eQBicbi7NdNEhSvyv+z4kjaRSR0czEt3MamlMVfeKMxeSujTlmjET2l4crpTd/YwK n5ZqzGWIKOjVaNl4xIjg9RtJW+hmYpmAXfm30= MIME-Version: 1.0 Received: by 10.236.109.19 with SMTP id r19mr680405yhg.289.1308734791880; Wed, 22 Jun 2011 02:26:31 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.110.141 with HTTP; Wed, 22 Jun 2011 02:26:31 -0700 (PDT) In-Reply-To: References: <201106191913.p5JJDOqJ006272@svn.freebsd.org> <20110622063258.D2275@besplex.bde.org> <4E0128FF.6020804@rice.edu> Date: Wed, 22 Jun 2011 11:26:31 +0200 X-Google-Sender-Auth: C32054n8MIHgdI9fKYrAh-1-tHU Message-ID: From: Attilio Rao To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: src-committers@freebsd.org, Alan Cox , 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 09:26:33 -0000 2011/6/22 Warner Losh : > > 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: > > =C2=A0Precisely document the synchronization rules for the page's dirty f= ield. > > =C2=A0(Saying that the lock on the object that the page belongs to must b= e > > held > > =C2=A0only represents one aspect of the rules.) > > =C2=A0Eliminate the use of the page queues lock for atomically performing > > 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=A0Co= uld 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 might > > not exist. =C2=A0Apparently they don't exist on mips. =C2=A0jake@ fixed a= ll 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. =C2=A0In 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 t= o > 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. =C2=A0Comments? > Warner That is wrong, of course, and my personal opinion is that one should not implement atomic operations if they cannot be done efficiently (example: if you need to disable interrupts or similar expensive operation just to assure atomicity of operation, just don't support it) as long as not having _8/_char is perfectly fine. Attilio --=20 Peace can only be achieved by understanding - A. Einstein