From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 12:43:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0EF31065674; Sun, 6 Nov 2011 12:43:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3188FC1B; Sun, 6 Nov 2011 12:43:35 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pA6ChWk6012841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2011 14:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pA6ChWlY054793; Sun, 6 Nov 2011 14:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA6ChVrE054792; Sun, 6 Nov 2011 14:43:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Nov 2011 14:43:31 +0200 From: Kostik Belousov To: Alan Cox Message-ID: <20111106124331.GP50300@deviant.kiev.zoral.com.ua> References: <4EB2D48E.1030102@rice.edu> <20111104100828.GG50300@deviant.kiev.zoral.com.ua> <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iK/U8+IrLmbLL9vI" Content-Disposition: inline In-Reply-To: <4EB595FA.4020500@rice.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: mdf@freebsd.org, "K. Macy" , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 12:43:36 -0000 --iK/U8+IrLmbLL9vI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote: > On 11/05/2011 10:15, Kostik Belousov wrote: > >On Sat, Nov 05, 2011 at 07:37:48AM -0700, mdf@freebsd.org wrote: > >>On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov = =20 > >>wrote: > >>>On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: > >>> > >>>Below is the KBI patch after vm_page_bits_t merge is done. > >>>Again, I did not spent time converting all in-tree consumers > >>>from the (potentially) loadable modules to the new KPI until it > >>>is agreed upon. > >>I like my bikeshed orange... > >> > >>I would think a more canonical name would be get/set rather than > >>read/write, especially since these operations aren't reading and > >>writing the page (neither are they getting the page, but at least set > >>is pretty unambiguous). > >Look at the vm_page.h:385. vm_page_set_valid() is already taken. >=20 > I don't feel good about creating an interface under which we have=20 > functions named vm_page_set_valid() and vm_page_write_valid(). I think= =20 > that we should take a step back and look at the whole of set of=20 > functions that exist for manipulating the page's valid and dirty field=20 > and see if we can come up with a logical schema for naming them. I=20 > wouldn't then be surprised if this results in renaming some of the=20 > existing functions. >=20 > However, this should not delay the changes to address the vm_page_lock=20 > problem. I had two questions about that part of your patch. First, is= =20 > there any reason that you didn't include vm_page_lockptr()? If we=20 > created the page locking macros that you, jhb@, and I were talking about= =20 > last week, then vm_page_lockptr() would be required. Second, there=20 > seems to be precedent for naming the locking functions _vm_page_lock()=20 > instead of vm_page_lock_func(), for example, the mutex code, i.e.,=20 > sys/mutex.h, and the vm map locking functions. I think vm_page_lockptr() should be included when some kind of reloc-iterating macros are actually introduced into the tree. And, I have a hope that they can be wrapped around a function with the signature like void vm_page_relock(vm_page_t locked_page, vm_page_t unlocked_page); which moves the lock from locked_page to unlocked_page. Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has a lot of violations in regard of the namespaces, IMO. The __* namespace is reserved for the language implementation, so our freestanding program (kernel) ignores the requirements of the C standard with the names like __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes it not unreasonable for other developers to introduce reserved names. So I decided to use the suffixes. vm_map.h locking is free of these violations. --iK/U8+IrLmbLL9vI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk62gPMACgkQC3+MBN1Mb4hMmQCeNIkyDL5uP3ZfnsmDyF0/vRFn X3QAnAo1an3qCsI+jdgUxl9Pk6ZTMDFV =MZ3u -----END PGP SIGNATURE----- --iK/U8+IrLmbLL9vI--