lock contention - what can we do about it?

[Milian Wolff]

Milian Wolff, 05.03.2011:
> David Nolden, 05.03.2011:
> > If the CPU time is below 100%, then that's for sure not due to lock
> > contention, but simply due to I/O. Either repeat the test with the
> > disk-cache better filled, or increase the number of threads.
> 
> If that would be the case, wouldn't iotop show lots of disk access? And
> top's %wa would be high, but it's rarely more than 2% for me (wa is iowait
> time).

also interesting:

top -p $(pidof duchainify) -H # -H for per-thread numbers

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                     
26756 milian    20   0  463m 107m  31m S   38  2.7   0:41.51 duchainify                  
26757 milian    20   0  463m 107m  31m S   32  2.7   0:33.79 duchainify                  
26747 milian    20   0  463m 107m  31m S    0  2.7   0:00.90 duchainify                  
26748 milian    20   0  463m 107m  31m S    0  2.7   0:00.00 duchainify                  
26749 milian    20   0  463m 107m  31m S    0  2.7   0:00.00 duchainify                  
26750 milian    20   0  463m 107m  31m S    0  2.7   0:00.00 duchainify                  
26751 milian    20   0  463m 107m  31m S    0  2.7   0:00.00 duchainify

instead of both at leas near 50% (better yet 100%)

I still think this is lock contention. how can we make sure?

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110305/08c692f0/attachment-0001.sig>