I am running a benchmark to figure out the number of jobs I should allow GNU Make to use in order to have optimal compile time. To do so, I am compiling Glibc with
make -j<N> with N an integer from 1 to 17. I did this 35 times per choice of N so far (35*17=595 times in total). I am also running it with GNU Time to determine the time spent and resources used by Make.
When I was analyzing the resulting data, I noticed something a little peculiar. There is a very noticeable spike in the number of major page faults when I reach
I should also note that 8 is the number of CPU cores (or number of hyper-threads to be more specific) on my computer.
I can also notice the same thing, but less pronounced, in the number of voluntary context switches.
To make sure my data wasn't biased or anything, I ran the test two more times and I still get the same result.
I am running artix linux with linux kernel 5.15.12.
What is the reason behind these spikes?
EDIT: I've done the same experiment again on a 4 cores PC. And I can observe the same phenomenon, at the 4 jobs mark this time around.
Also, notice the jump in major page faults in the 2 jobs mark.
@FrédéricLoyer suggested comparing page faults with the efficiency (inverse of the elapsed time). Here is a box plot of exactly that:
We can see that the efficiency is getting better as we go from 1 job to 4 jobs. But it stays basically the same for bigger numbers of jobs.
I should also mention that my system has enough memory so that even with the maximum number of jobs, I do not run out of memory. I am also recording the PRSS (peak resident set size) and here is a box plot of it.
We can see that the number of jobs doesn't impact memory usage at all.
EDIT3: As MC68020 suggested, here are the plots for TLBS (Transaction Lookaside Buffer Shootdown) values for 4 cores and 8 cores systems, respectively: