Lock profiling results on TCP and an 8.x project

[Kip Macy]

On 10/21/07, Robert Watson <rwatson at freebsd.org> wrote:
> On Sat, 20 Oct 2007, Robert Watson wrote:
>
> > * When talking about percentage of available CPUs, I make the assumption
> > that
> >  due to a sufficient quantity of CPUs, in most cases lock acquisition will
> >  occur as a result of adaptive spinning rather than sleeping.  In the
> > netperf
> >  case, this is not true, since the number of potential workers exceeds the
> >  number of CPUs, hence the turnstile contention.  However, as sleeping on
> >  locks itself is very expensive, it's reasonable to assume we would recover
> >  a lot of CPU none-the-less.
>
> FYI, a feature request for lock profiling: it would be nice if we also tracked
> for each contention point time spent spinning vs. context switched waiting for
> the lock, and the number of context switches the lock acquisition point has
> caused.  This would allow us to better understand the impact of adaptive lock
> behavior for workloads and configurations.

This would involve changing acquisition wait time into 3 fields:
- time spent spinning
- time spent context switched out
- number of context switches

The lock profiling object is fairly large as it is, so ideally this
would happen after I've moved the lock_profile_object out of the
lock_object. That is work that I've already mostly done as part of
making profiling work for shared acquisitions and having it not break
the ABI when enabled. Unfortunately, I haven't had time to make it
commit-ready - so if someone wants to jump in and implement Robert's
idea before that happens I won't object.

 -Kip