Date: Mon, 7 Nov 2011 21:58:33 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: mdf@FreeBSD.org Cc: "K. Macy" <kmacy@FreeBSD.org>, Alan Cox <alc@rice.edu>, Andriy Gapon <avg@FreeBSD.org>, freebsd-current@FreeBSD.org, Benjamin Kaduk <kaduk@mit.edu>, Penta Upa <bsdboot@gmail.com> Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] Message-ID: <20111107195833.GB50300@deviant.kiev.zoral.com.ua> In-Reply-To: <CAMBSHm-iNCbhLKrFuaLta4rSPo-5fr_AnaTpsKk2qnpjxLMzwQ@mail.gmail.com> References: <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <CAMBSHm86TaJnRRgmPA_t7tiPfQsPyoTqz3ymdHSY1H3t5G864Q@mail.gmail.com> <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> <CAMBSHm-iNCbhLKrFuaLta4rSPo-5fr_AnaTpsKk2qnpjxLMzwQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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 <kostikbel@gmail.com> wrote:
> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
> >> Ok. I'll offer one final suggestion. Please consider an alternative
> >> suffix to "func". Perhaps, "kbi" or "KBI". In other words, something
> >> 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 simplification
> > 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)
> > vm_page_dirty(m);
> > }
> >
> > +void
> > +vm_page_lock_KBI(vm_page_t m, const char *file, int line)
> > +{
> > +
> > +#if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE)
> > + _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
> > +#else
> > + __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)
> > + _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
> > +#else
> > + __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)
> > +{
> > +
> > + 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
> > + _mtx_assert(vm_page_lockptr(m), a, file, line);
> > +#endif
> > +}
> > +
> > int so_zerocp_fullpage = 0;
> >
> > /*
> > 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[];
> >
> > #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
> >
> > +#ifdef KLD_MODULE
> > +#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE, LOCK_LINE)
> > +#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE, LOCK_LINE)
> > +#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE, LOCK_LINE)
> > +#ifdef INVARIANTS
> > +#define vm_page_lock_assert(m, a) \
> > + vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
> > +#else
> > +#define vm_page_lock_assert(m, a)
> > +#endif
> > +#else /* KLD_MODULE */
> > #define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m))))
>
> 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.
>
> 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.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk64OGkACgkQC3+MBN1Mb4jJqwCglyA2fHh1mVljLEMhXz6p2dgX
MNQAn2uDvMejSJFSA7ISTaWrNnEDGYcb
=8Xfz
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111107195833.GB50300>