On Wed, 2026-04-15 at 13:27 -0400, Paul Smith wrote:
>
> Can you please try applying this patch and rebuilding GNU Make, and
> see
> if you get better results in your tests; this goes back (basically)
> to
> the older algorithm:
>
> --- a/src/job.c
> +++ b/src/job.c
> @@ -2057,7 +2057,7 @@ load_too_high (void)
> #else
> static double last_sec;
> static time_t last_now;
> - static int proc_fd = -2;
> + static int proc_fd = -1;
>
> double load, guess;
> time_t now;
Thanks, with this patch applied it does look better indeed.
It is difficult to really observe the absence, but it does "feel"
better, since the device no longer freezes for extended periods of
time. After the machine chokes on a big file, completed jobs are not
replaced with new tasks until things settle down. That's the good
thing.
The bad thing is that once things do settle down, it immediately starts
as many jobs as allowed by --jobs parameter, which on a moderately
loaded machine results in oscilations: Suddenly starting a bunch of
jobs pushes the load way above limit, then new jobs get held back, so
the machine idles waiting for load estimate to go down, and then we go
pedal to the metal overwheling it again and restarting the cycle.
I mean, I can see why someone wanted to make it better.
Maybe the old algorithm you mentioned just needs a rate limit on adding
new parallel jobs instead of a whole new, better load estimation
though?
Say, a rule like "every 5 seconds increase current parallelism by
(target load - current load)/2"?
Kinda mirroring TCP's behavior in face of congestion. Should nicely
smooth things out. Just putting it here as an idea.
The 5 seconds suggested here matches how often linux kernel updates its
own load average.
