Hello,
the ChangeLog says the following:
2019-12-17 Paul Smith <psm...@gnu.org>
...
* src/job.c (load_too_high): Disable Linux /proc/loadavg for now
This new feature has a problem: if you provide a load which is
larger than the number of cores then it will always run every job.
Before we can enable it we need to at the least learn how to clamp
this value to the number of cores. To experiment with it, set
PROC_FD_INIT to -2 in job.c to re-enable the feature.
I have recently been looking into this again, because of a new feature I
am currently testing, and so far can only repeat what I have already
said in the past. The /proc/loadavg file under Linux with a vanilla
kernel is behaving as expected, meaning, the number of active processes
can very well exceed the number of cores.
To quote from the Linux source code documentation under
Documentation/filesystems/proc.rst:
loadavg Load average of last 1, 5 & 15 minutes;
number of processes currently runnable (running or on
ready queue);
total number of processes in system;
last pid created.
All fields are separated by one space except "number of
processes currently runnable" and "total number of
processes
in system", which are separated by a slash ('/'). Example:
0.61 0.61 0.55 3/828 22084
Here it states that it is the number of running or ready processes. Any
implementation of /proc/loadavg which counts only one running process
per core is effectively counting the number of active cores, but not the
number of running or runnable processes, and should therefore be
considered buggy or deviant.
Thus, when there is a deviant implementation of /proc/loadavg out there,
by a modified Linux kernel or perhaps another OS, then we should gate
this off either through autoconf or a simple #ifdef linux #endif.
Sven
