PERFORCE change 100089 for review

[Kip Macy]

I've mapped your uipc_usrreq.c into my tree and have seen a measurable
boost. I actually see no contention on it. If I go into overload (16
threads) I see the following:

    65     13580255    555960120     4332486     3   128     22050892
    4323043 /flatstor/shared/p4/sun4v/work_sleepq/src/sys/kern/kern_synch.c:217
(lockbuilder mtxpool)
    13     24053476    160697931    92708398     0     1     30726211
          0 /flatstor/shared/p4/sun4v/work_sleepq/src/sys/kern/kern_switch.c:522
(runq lock)
   371     63389470     27487168      936871    67    29      5918460
     640938 /flatstor/shared/p4/sun4v/work_sleepq/src/sys/kern/kern_lock.c:163
(lockbuilder mtxpool)
    39     36405448     10970117     4748316     7     2      4132590
          0 /flatstor/shared/p4/sun4v/work_sleepq/src/sys/kern/kern_switch.c:221
(runq lock)
   361     85861725     10866103     5699832    15     1      3813907
          0 /flatstor/shared/p4/sun4v/work_sleepq/src/sys/kern/subr_sleepqueue.c:223
(sleepq chain)

lockmgr is my biggest problem now.

On 6/26/06, Robert Watson <rwatson at freebsd.org> wrote:
> On Mon, 26 Jun 2006, John Baldwin wrote:
>
> > On Monday 26 June 2006 16:54, Kip Macy wrote:
> >> http://perforce.freebsd.org/chv.cgi?CH=100089
> >>
> >> Change 100089 by kmacy at kmacy_storage:sun4v_work_sleepq on 2006/06/26
> > 20:53:51
> >>
> >>      add profiling for rwlocks
> >>      not convinced of correctness as there don't appear to be any contended
> > rwlocks on my workloads
> >
> > Few things use them currently.  I have a patch to make the name cache use
> > them if you want it.
>
> You may already have seen this, but I have a UNIX domain socket re-locking in
> //depot/user/rwatson/proto/src/sys/kern/uipc_usrreq.c that uses rwlocks and
> finer-grained mutexes, among other things.  Ideally this can generate some
> contention (although perhaps not too much).
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>