Default MAKEFLAGS in makepkg.conf causing CPU overloading

4th (6.0.1-4) pacman wrapper version introduced CPU overloading bug in makepkg.conf

The update list excerpt:

Package (78)                              Old Version              New Version              Net Change  Download Size
core/pacman                               6.0.1-3                  6.0.1-4                   -0.24 MiB       1.13 MiB

According to nproc arg definition (makepkg - ArchWiki) the initial good idea was nproc - 1, perhaps.

i have;


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
  File: /desktopfs-pkgs.txt
  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 :man_shrugging:
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 $(nproc)-1:

1 Like

See makepkg - ArchWiki

1 Like

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)

1 Like

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.