svn commit: r304436 - in head: . sys/netinet

[Slawa Olhovchenkov]

On Sat, Aug 27, 2016 at 07:05:01PM -0700, Adrian Chadd wrote:

> On 26 August 2016 at 17:46, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> > On Fri, Aug 26, 2016 at 04:55:34PM -0700, Adrian Chadd wrote:
> >
> >> Hi,
> >>
> >> I use the kernel lock profiling debugging,
> >
> > I am already have 100% utilise all CPU cores, I think this is drop
> > performance?
> >
> >> but you can use dtrace to
> >> get an idea:
> >>
> >> dtrace -n 'lockstat:::adaptive-block { @[stack()] = sum(arg1); }'
> >
> > How to interpret results (how to distinct lock contention from lock
> > cost/overhead (LOCK CMPXCGQ is very expensive))?
> 
> well, paste the results? :)

OK, thanks!
http://m.uploadedit.com/ba3s/1472390519813.txt

> the lock is expensive because it's contended. :)

As I am understund lock contended:

1. Multiple thread wait same lock.
2. Performance not scaled by adding CPU power

As I understund lock expensive: Intel cache coherence protocol is
expensive and take lock 800K per second take too much cpu/memory
bandwidth w/o any contention. Memory latency at cache miss too.

Adding mory CPU power (more cores, more GHz) take me performane boost.
I am think my case is not lock contended.

> >> (https://wiki.freebsd.org/DTrace/One-Liners)
> >>
> >>
> >>
> >> -adrian