Date: Fri, 28 Jun 2013 10:10:04 +0200 From: Attilio Rao <attilio@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: svn commit: r252209 - in head: share/man/man9 sys/kern sys/sys Message-ID: <CAJ-FndDzKjKf3tE9pgTF2WisRwf%2BK=Ju0vhXnPyd=iBTkZGdyA@mail.gmail.com> In-Reply-To: <201306271034.11852.jhb@freebsd.org> References: <201306251844.r5PIiFDZ009708@svn.freebsd.org> <51CA97AE.4090306@freebsd.org> <201306271034.11852.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 27, 2013 at 4:34 PM, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday, June 26, 2013 3:26:38 am Andre Oppermann wrote: >> On 25.06.2013 20:44, John Baldwin wrote: >> > Author: jhb >> > Date: Tue Jun 25 18:44:15 2013 >> > New Revision: 252209 >> > URL: http://svnweb.freebsd.org/changeset/base/252209 >> > >> > Log: >> > Several improvements to rmlock(9). Many of these are based on patches >> > provided by Isilon. >> > - Add an rm_assert() supporting various lock assertions similar to other >> > locking primitives. Because rmlocks track readers the assertions are >> > always fully accurate unlike rw_assert() and sx_assert(). >> > - Flesh out the lock class methods for rmlocks to support sleeping via >> > condvars and rm_sleep() (but only while holding write locks), rmlock >> > details in 'show lock' in DDB, and the lc_owner method used by >> > dtrace. >> > - Add an internal destroyed cookie so that API functions can assert >> > that an rmlock is not destroyed. >> > - Make use of rm_assert() to add various assertions to the API (e.g. >> > to assert locks are held when an unlock routine is called). >> > - Give RM_SLEEPABLE locks their own lock class and always use the >> > rmlock's own lock_object with WITNESS. >> > - Use THREAD_NO_SLEEPING() / THREAD_SLEEPING_OK() to disallow sleeping >> > while holding a read lock on an rmlock. >> >> Thanks! >> >> Would it make sense to move struct rm_queue from struct pcpu itself to >> using DPCPU as a next step? > > Perhaps. It might make pcpu.h cleaner, aside from that concern I don't think > it really matters much. It cannot for performance reasons. I had a comment ready for this but I'm not sure if it was ever committed. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndDzKjKf3tE9pgTF2WisRwf%2BK=Ju0vhXnPyd=iBTkZGdyA>