Reaction score: 357
Any idea how I can make the CPU go to 100% during a make ?
Why the question mark?I've set the number of make jobs to 15 in make.conf
Make will spawn compiler processes. Do you see clang or clang++?But ps aux shows only 4 make jobs. Maybe it spawns threads or it can't be paralised ?
/bin/sh -e -c (cd /wrkdirs/usr/ports/www/qt5-webengine /usr/local/libexec/ccache/c++ /usr/bin/c++
FreeBSD clang version 11.0.1 (firstname.lastname@example.org:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd13.0 Thread model: posix
I have some doubts about that from what I observe on my builder with these specs:Compiles will probably not do it; for most programming languages, make is IO limited, no CPU limited.
ALLOW_MAKE_JOBS_PACKAGES, the CPU stays at 100% constantly. The only thing that can sometimes make it wait for I/O is a very good cache hit rate from
Reaction score: 94
Same with synth with setting it to use ram for the build environment and for the workdir. When it decides to try building several big packages in parallel with -j4 I see load hit 13 (on four core i5). Strangely, the system is still completely responsive even in fluxbox/Xorg.Not sure. I had no trouble maxing out all my cores running Poudriere jobs. What's the load average during your runs?
Modern CPU schedulers are black magic for sure, but most use adaptive priorities to ensure "fairness". This means scheduling priorities change based on previous behavior of the process. A very simple (but already somewhat effective) idea is to look at how often a process uses the full time slice it gets. A process using full time slices will be prioritized down. This is true for your typical compiler. In an initial parsing phase, reading all the required input files, it might block quite often waiting for I/O, but once it has everything it needs, the actual compilation just uses CPU time, so it's full time slices for a while. In contrast, the processes driving your desktop UI will almost never use a full time slice, as they're most of the time waiting for some input (like e.g. a mouse click), blocking until something is happening. So, this simple heuristics would already lead to the scheduler prefering your "fluxbox" process to the "clang" process There are probably a lot more elaborate ideas implemented as well.I see load hit 13 (on four core i5). Strangely, the system is still completely responsive even in fluxbox/Xorg.
nice -n 20for my poudriere builds. This way, even loads of 30 to 40 (on a quad-core with hyperthreading) most of the time don't disturb other, more interactive, processes on the same machine.
This is in line with my observations. It seems the scheduler's "intelligence" improved in 13.With FreeBSD12 I was able to disturb the realtime attitude of my PC during builds like e.g. "rust", i.e. youtube would start to stutter.
With FreeBSD13 I can no longer. Youtube just continues to play fine.