I have a 4-core 8-thread CPU. I switched from Windows 7 to Manjaro last summer.
I have been using Pamac for regular updates and yay for updates Pamac seems too buggy to see despite manual refreshes. Whenever I update a -git package, it uses all my CPU threads, limiting performance of single-threaded applications severely.
On Windows, when I built software from source with GCC in msys2, I always limited the number of threads used to 7, so I could have 1 thread free to comfortably use my computer while building. I achieved this by building these projects with my very own bash scripts which I painstakingly made for each project I built.
I would like to achieve the same thing in Manjaro, but without having to edit each -git package’s build files. Is there a comfortable way (with any package manager) to limit CPU core usage to a particular number for the entire package manager in all sessions without having to edit each individual package’s build files?
Thanks for any leads you can provide, even if they do not answer the question directly.
Look in /etc/makepkg.conf.
Find the line containing MAKEFLAGS= and uncomment it if it’s commented.
Change it to -jX where X is the number of cores you want it to use.
Save the file (you need root/sudo for this)
It currently says MAKEFLAGS="-j$(($(nproc)+1))". I wonder If I could just remove the +1 and that would always make it use 1 fewer thread than my CPU has. Do you think so?
For now, I’m setting it to just MAKEFLAGS="-j7" to experiment in a simple way.
OK. I wonder if I could use -1 instead. It would be nice to have this work well on any CPU or VM that I copy my whole config to in the future. I’ll try -1. Thanks again! I’m marking your first post as the solution.
OK, I tested with -1, and that seemed to do very little. I could see in ksysguard that all 8 of my cores were nearly maxed out. I tested with -2 next and that seemed to look the same as -1, but I wasn’t sure if that was placebo, so I tested with -7. That then had all 8 of my threads around 10-20% usage. So, this is so weird. It’s not limiting to specific threads like it does with the -jX parameter in Windows. It seems to spread the remaining usage among all the threads anyway, so I can’t get max performance from 1 thread in particular this way.
It’s still way better that I can reduce the total CPU usage. I guess I shouldn’t use subtraction though, because if I’m running this in a VM which has only 4 threads available, for example, -7 would really bust things. I’ll stick with -j5 or something so I get at least some headroom for other software.
I really wish I could limit it to 7 particular threads and have those 7 used to the max while 1 thread is conspicuously free, like I saw in Windows, but I guess that’s just a difference in how these OSes operate.
I hope this thread helps someone else in the future! Thanks again, Strit, for your help. This had been bugging me for months and the solution was so simple!
-j means jobs, nproc will count the available CPU threads. "-j$(($(nproc)+1))" will use all available CPU threads and queue a job (the +1) for when a running job completes and a thread is free. In this regard it is faster than "-j$(nproc)" as there’s always one job waiting to hand off to a free thread instead waiting for a free thread to find a new job.
Is there a way to limit each job to 1 CPU thread? I was expecting to see 1 thread with 100% usage with -j1 but saw 8 threads with ~1/8 usage each instead.
I mean since the job is being split among many threads anyway, but is being split without necessity. This means that it must be doing a ton of context-switching which seems quite wasteful. Is there a way or not?
I saw it with retroarch-git, xfce4-panel-git, and ytfzf-git. Which threads are used seems to switch like crazy while all threads stay above a minimum of ~15%. Here’s a screenshot with -j3 from ksysguard while building those projects.
