and yesterday update required a merge, but ‘MAKEFLAGS’ had no changes. the only changes required were to introduce;
and dropping of “-fvar-tracking-assignments” from ‘DEBUG_CFLAGS’ and ‘DEBUG_CXXFLAGS’
i do agree though ‘nproc+1’ makes no sense, and since corrected to ‘nproc’. which value “overloaded” yours?
According to GitLab this change was introduced 2021-11-24 (more than 3 months ago):
although it looks like the actual first
pacman package update including this change was 6.0.1-3 which my system got 2022-01-09.
answer to Koshika
Hi! Thanks for the reply.
I got the same as new after the update I did a couple hours ago.
I do update a few times per week, not every day, and I have ‘MAKEFLAGS’ change from my current old -j2 to that new on value.
I think that it is the simultaneously thread count of compiling files. +1 thread of the machine have overloads CPU: one of cores constantly switches between threads which leads to CPU core to wait get and send data (instructions and payload data), which makes such core to be unfective.
Also using all threads which a machine has leads to reduce of CPU response time and such PC lags on other user tasks.
nproc - 1 looks like perfect balance between compilation speed vs PC response for other user actions during a package compilation in a background.
That’s strange cause I installed the OS copy on
stat /desktopfs-pkgs.txt 15:00:57
Size: 24445 Blocks: 48 IO Block: 4096 regular file
Device: 0,26 Inode: 65108 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-02-10 21:50:34.015052180 +0300
Modify: 2022-02-19 06:01:37.000000000 +0300
Change: 2022-02-10 21:50:34.015052180 +0300
Birth: 2022-02-10 21:50:34.015052180 +0300
and I had the
MAKEFLAGS= as the commented line and uncomment it manually to speed up compile process.
May be I do not remember correctly some details.
To the current state of the
/etc/makepkg.conf file: do you agree that
nproc - 1 value is optimum default,
and the values of [
nproc (which makes a PC to lag on other user activity)
nproc + 1 (which leads to overload a CPU)
] are not optimum defaults?
I cannot see the reason for this change, looks like a typo to me
As I do not build that much (AUR) packages myself and like to use my machine in rather quite mode, my approach is even more conservative than
Mark, you point me the same link I pointed in the initial post.
So it looks like the decision was based on general info from Arch wiki article without corrections to a real world conditions. For example, for my current 2 and 4 cores 4 CPUs (on both PCs) the
nproc + 1 value is a killing feature for PC respond time.
I just suggest to re-think the value to apply to a wider user usage, but if it is the issue only for me and @freggel.doe , we can edit the value manually to do not compromise other user compilation speed and usage profile only cause our both usage preferences.
I guess that “respond time” during a compilation was not the goal or a priority - but rather a quick compilation/effcient use of available resources to get the task done.
I have used that (one more than I have cores) for a very long time (many years).
If response time is an issue you could either adapt that setting
or run/start the compilation with
nice 19 ...
(lowest priority, but still utilizing all the cores)
No, it doesn’t. Full load =/= overloading.
So what potato are you having issues with? You know the drill.
Otherwise this post is pointless and anecdotal.