<p>I'm just saying that the <100% is due to I/O. There is no other possible explanation anyway, unless if some thread would take a lock and start sleeping while holding it.</p>
<p>The fact that we don't use all cores is due to lock contention of course. Using SpinLock instead of QMutex in the whole duchain would have many advantages:<br>
a) It can be debugged<br>
b) It is less buggy (100 LOC instead of a few thousand provenly buggy LOC..)<br>
c) It is probably faster, at least when the protected region is very small, as is usually the case in the duchain<br>
d) It would allow us to analyze lock contention using valgrind, by disabling all sleeping in the spinlock and in the duchain lock</p>
<p>Anyway, personally I don't care so much about the lock contention. What I see though is, that all the statistics, analyzes and hypotheses that have been done regarding this issue simply are not useful to do anything about it. If you want to fix something, then you need to know: Which exact lock is responsible for most of the contention, and from where is it called? This could be answered by valgrind with spin-locks.</p>
<p>There would be even more useful statistics, like "Who is holding the lock while we're waiting for it, and what is he doing?", but that would be pretty hard to answer.</p>
<p><blockquote type="cite">Am 06.03.2011 22:58 schrieb "Milian Wolff" <<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>>:<br><br>David Nolden, 06.03.2011:<br>
<p><font color="#500050">> When doing "./duchainify --threads 10 -f all-declarations-and-uses<br>> my-project --force-update" I ...</font></p>Sorry David, but I cannot follow you here. With 10 threads you should ideally<br>
up to ten cores busy, but well - on the ubiquotos dual core machines of today<br>
(which I assume you have as well) at least 200%. How your number "proofs" that<br>
it's IO wait I have no idea.<br>
<br>
Furthermore please take my other emails into account, i.e. wa / iowait time as<br>
reported by top or vmstat, or general reads reported by iotop or or or...<br>
<p><font color="#500050"><br>> That mutrace output does not really look useful.<br></font></p>Yep, I wonder what we can do about it. I wonder whether it's not maybe that my<br>
Qt lib is missing debug symbols, I'll retry that one.<br>
<p><font color="#500050"><br>> I just got an idea<br>> how we can very simply fight the lock contention: Simply replace all<br>> uses ...</font></p>Really? I'd rather use Qt code than custom code. I'm against this change.<br>
<p><font color="#500050"><br>> For profiling, we can then<br>> simply disable the QWaitCondition fallback in SpinLock, which means<br>...</font></p>Ah, you mean only for profiling? It would still mean tons of ifdefs and stuff<br>
like that, nothing I want to pollute our codebase with. But one could think<br>
about maintaining a patch(-set) for that and see what output it produces...<br>
<br>
Still, I cannot believe that the tools (drd, mutrace, ... ?) are really not<br>
sufficient for our case. We are not the only ones with such problems after<br>
all.<br>
<br>
bye<br>
<p><font color="#500050"><br>-- <br>Milian Wolff<br><a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a><br><a href="http://milianw.de" target="_blank">http://milianw.de</a></font></p><br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org" target="_blank">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></p>