Hey Rainer, > On 15 Jan 2019, at 17:27, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>>> On 14 Jan 2019, at 13:53, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: >>> >>> "MCC CS" <mc...@gmx.com> writes: >>> >>>> I've been running the testsuite on my macOS, on which >>>> it is especially unbearable. I want to (at least try to) >>> >>> that problem may well be macOS specific: since at least macOS 10.13 >>> (maybe even 10.12; cannot currently tell for certain) make -jN check >>> times on my Mac mini skyrocketed with between 60 and 80% system time. >>> It seems this is due to lock contention on one specific kernel lock, but >>> I haven't been able to find out more yet. >> >> this PR mentions the compilation, but it’ even more apparent on test. >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257 >> >> * Assuming SIP is disabled. >> >> Some testing suggests that each DYLD_LIBRARY_PATH entry adds around 2ms to >> each exe launch. >> So .. when you’re doing something that’s a lot of work per launch, not much >> is seen - but when you’re doing things with a huge number of exe launches - >> e.g. configuring or running the test suite, it bites. >> >> A work-around is to remove the RPATH_ENVAR variable setting in the top >> level Makefile.in (which actually has the same effect as running things >> with SIP enabled) > > this change alone helped tremendously: a bootstrap on macOS 10.14 on > 20181103 took > 180041.05 real 96489.89 user 180864.44 sys > > while the current one was only > > 44886.30 real 74101.86 user 36879.75 sys > > However, not unexpectedly quite a number of new failures occur, > e.g. many (all?) plugin tests FAIL with > > cc1: error: cannot load plugin ./selfassign.so > dlopen(./selfassign.so, 10): Symbol not found: __ZdlPvm > Referenced from: ./selfassign.so > Expected in: /usr/lib/libstdc++.6.dylib > in ./selfassign.so > compiler exited with status 1 > > I'll still have to check which are affected this way. I’m afraid that with this (or with SIP enabled) “uninstalled testing” can’t work, the libraries have to be found from their intended installed path, so you have to “make install && make check” ** and remember to delete the install before building the next revision... >> === DejaGNU on macOS... >> >> DejaGNU / expect are not fantastic on macOS, even given the comments above >> - it’s true. Writing an interpreter/funnel for the testsuite has crossed >> my mind more than once. >> >> However, I suspect it’s a large job, and it might be more worth investing >> any available effort in debugging the slowness in expect/dejaGNU - >> especially the lock contention that Rainer mentions. > > Indeed: I found it when trying to investigate the high system time with > lockstat. However, I don't know a way how to relate the lock address > mentioned there to some lock in the darwin sources. Well.. let’s take this offline - or park it in a BZ somewhere, if you can be more specific - would be happy to poke at it a bit : if it’s a genuine OS bug, we can file a radar - but that doesn’t help the system versions out of support. (and there’s enough useful h/w out there that’s tied to 10.11 etc) Iain
