lock contention - what can we do about it?

[Milian Wolff]

Milian Wolff, 05.03.2011:
> 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?

if someone is running fedora, maybe he can try to use systemtap to sum the 
amount of time spent in QMutex::lock() - I'd be very interested in this 
number.

Too bad that systemtap still requires custom patches on ubuntu, anyone knows 
whether it's simpler on archlinux?

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/54216c7e/attachment.sig>