lock contention - what can we do about it?

[Milian Wolff]

David Nolden, 06.03.2011:
> When doing "./duchainify --threads 10 -f all-declarations-and-uses
> my-project --force-update" I get a CPU usage of about 90%, which shows
> that I/O is probably the reason why you reach only low values.

Sorry David, but I cannot follow you here. With 10 threads you should ideally 
up to ten cores busy, but well - on the ubiquotos dual core machines of today 
(which I assume you have as well) at least 200%. How your number "proofs" that 
it's IO wait I have no idea.

Furthermore please take my other emails into account, i.e. wa / iowait time as 
reported by top or vmstat, or general reads reported by iotop or or or...

> That mutrace output does not really look useful.

Yep, I wonder what we can do about it. I wonder whether it's not maybe that my 
Qt lib is missing debug symbols, I'll retry that one.

> I just got an idea
> how we can very simply fight the lock contention: Simply replace all
> uses of QMutex with uses of SpinLock.

Really? I'd rather use Qt code than custom code. I'm against this change.

> For profiling, we can then
> simply disable the QWaitCondition fallback in SpinLock, which means
> that the lock will be doing an endless loop with 100% CPU
> utilizitation while waiting. In turn, this means that we will see the
> "waiting" time in the callgrind output, fairly compared to everything
> else that is slowing down the application.

Ah, you mean only for profiling? It would still mean tons of ifdefs and stuff 
like that, nothing I want to pollute our codebase with. But one could think 
about maintaining a patch(-set) for that and see what output it produces...

Still, I cannot believe that the tools (drd, mutrace, ... ?) are really not 
sufficient for our case. We are not the only ones with such problems after 
all.

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/20110306/92037956/attachment-0001.sig>