lock contention - what can we do about it?
Milian Wolff
mail at milianw.de
Sun Mar 6 21:56:54 UTC 2011
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>
More information about the KDevelop-devel
mailing list