From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:58:37 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 A22011065673; Mon, 7 Nov 2011 19:58:37 +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 372D78FC13; Mon, 7 Nov 2011 19:58:36 +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 pA7JwXhX085850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2011 21:58:33 +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 pA7JwX3h061202; Mon, 7 Nov 2011 21:58:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pA7JwXZe061201; Mon, 7 Nov 2011 21:58:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Nov 2011 21:58:33 +0200 From: Kostik Belousov To: mdf@FreeBSD.org Message-ID: <20111107195833.GB50300@deviant.kiev.zoral.com.ua> References: <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> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Iyp50ur6m8WkwkNM" Content-Disposition: inline In-Reply-To: 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: "K. Macy" , Alan Cox , 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: Mon, 07 Nov 2011 19:58:37 -0000 --Iyp50ur6m8WkwkNM Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 07, 2011 at 11:47:59AM -0800, mdf@FreeBSD.org wrote: > On Mon, Nov 7, 2011 at 11:35 AM, Kostik Belousov wr= ote: > > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > >> Ok. =9AI'll offer one final suggestion. =9APlease consider an alternat= ive > >> suffix to "func". =9APerhaps, "kbi" or "KBI". =9AIn other words, somet= hing > >> that hints at the function's reason for existing. > > > > Sure. Below is the extraction of only vm_page_lock() bits, together > > with the suggested rename. When Attilio provides the promised simplific= ation > > of the mutex KPI, this can be reduced. > > > > diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c > > index 389aea5..ea4ea34 100644 > > --- a/sys/vm/vm_page.c > > +++ b/sys/vm/vm_page.c > > @@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m) > > =9A =9A =9A =9A =9A =9A =9A =9Avm_page_dirty(m); > > =9A} > > > > +void > > +vm_page_lock_KBI(vm_page_t m, const char *file, int line) > > +{ > > + > > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > > + =9A =9A =9A _mtx_lock_flags(vm_page_lockptr(m), 0, file, line); > > +#else > > + =9A =9A =9A __mtx_lock(vm_page_lockptr(m), 0, file, line); > > +#endif > > +} > > + > > +void > > +vm_page_unlock_KBI(vm_page_t m, const char *file, int line) > > +{ > > + > > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > > + =9A =9A =9A _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line); > > +#else > > + =9A =9A =9A __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line= ); > > +#endif > > +} > > + > > +int > > +vm_page_trylock_KBI(vm_page_t m, const char *file, int line) > > +{ > > + > > + =9A =9A =9A return (_mtx_trylock(vm_page_lockptr(m), 0, file, line)); > > +} > > + > > +void > > +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line) > > +{ > > + > > +#ifdef INVARIANTS > > + =9A =9A =9A _mtx_assert(vm_page_lockptr(m), a, file, line); > > +#endif > > +} > > + > > =9Aint so_zerocp_fullpage =3D 0; > > > > =9A/* > > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > > index 7099b70..a5604b7 100644 > > --- a/sys/vm/vm_page.h > > +++ b/sys/vm/vm_page.h > > @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[]; > > > > =9A#define =9A =9A =9A =9APA_LOCK_ASSERT(pa, a) =9A mtx_assert(PA_LOCKP= TR(pa), (a)) > > > > +#ifdef KLD_MODULE > > +#define =9A =9A =9A =9Avm_page_lock(m) =9A =9A =9A =9A vm_page_lock_KB= I((m), LOCK_FILE, LOCK_LINE) > > +#define =9A =9A =9A =9Avm_page_unlock(m) =9A =9A =9A vm_page_unlock_KB= I((m), LOCK_FILE, LOCK_LINE) > > +#define =9A =9A =9A =9Avm_page_trylock(m) =9A =9A =9Avm_page_trylock_K= BI((m), LOCK_FILE, LOCK_LINE) > > +#ifdef INVARIANTS > > +#define =9A =9A =9A =9Avm_page_lock_assert(m, a) =9A =9A =9A \ > > + =9A =9Avm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE) > > +#else > > +#define =9A =9A =9A =9Avm_page_lock_assert(m, a) > > +#endif > > +#else =9A/* KLD_MODULE */ > > =9A#define =9A =9A =9A =9Avm_page_lockptr(m) =9A =9A =9A(PA_LOCKPTR(VM_= PAGE_TO_PHYS((m)))) >=20 > Is it not possible to have vm_page_lockptr() be a function for the > KLD_MODULE case? Because then the vm_page_lock() functions and > friends would all just use mtx_lock, etc., in both the KLD and non-KLD > case. >=20 > Or am I missing something? It is possible, but I tried to avoid exposing lockptr. IMHO vm_page_lockptr() is an implementation detail. Please also see my other response to Alan regarding the relocking macros. --Iyp50ur6m8WkwkNM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk64OGkACgkQC3+MBN1Mb4jJqwCglyA2fHh1mVljLEMhXz6p2dgX MNQAn2uDvMejSJFSA7ISTaWrNnEDGYcb =8Xfz -----END PGP SIGNATURE----- --Iyp50ur6m8WkwkNM--