Allan Sandfeld Jensen wrote:
> It only launches one ninja process, and ninja guesses the number threads > itself by using cpuinfo (unless you control it with NINJAFLAGS), but that > can't get load to 60. I would guess the load is not from CPU, but maybe memory > load, if you start swapping other processes could end up waiting on swapped > out memory, which could theoretically get the load to 60. This is on OS X 10.9, where swapping is unlikely to happen (and htop only showed a tiny bit in use). From 10.9 onwards there are other advanced memory management features like compression that must come at a cost too. But either way, I'm used to see "kernel_task" pop up when system_time CPU load increases, and it didn't here. Your explanation does sound plausible, though. Even if the memory monitoring thingy I'm running didn't put up the alert I'd expect in that kind of situation, and the system was surprisingly responsive even when I went back to my local session (I'd been monitoring remotely). I don't use NINJAFLAGS myself, but maybe it's set in the Makefile that calls ninja, as a function of the -j number make has been called with? Also, I interrupted the process shortly after posting this message, and restarted the build without -j. I still saw peak loads up to 30, but that's already quite a bit less. And I'd say there were indeed less concurrent clang processes. BR, René _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
