> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
There have been many other good suggestions of choices for make -j and the
choice depends
DSB wrote:
> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
>
>
> This is an interesting question and I suppose the answer
>
> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
>
This is an interesting question and I suppose the answer depends on many
factors. At my
> Date: Fri, 12 Apr 2024 07:58:28 +0200
> From: Henrik Carlqvist
> Cc: bug-make@gnu.org, matt.stav.tay...@gmail.com
>
> On Fri, 12 Apr 2024 02:13:36 +0100
> Matt Staveley-Taylor wrote:
> > Browsing the mailing list I can see that the behaviour of -j with no
> > arguments has been discussed a
On Fri, 12 Apr 2024 02:13:36 +0100
Matt Staveley-Taylor wrote:
> Browsing the mailing list I can see that the behaviour of -j with no
> arguments has been discussed a few times. Given it would affect
> backwards compatability to change how -j works, introducing a new
> flag seems appropriate.
Add the -J/--detect-job-slots flag as an shorthand equivalent for
-j$(nproc). The help message is deliberately left ambiguous so that we
could change it to nproc + 1 in future, if desired.
Signed-off-by: Matt Staveley-Taylor
---
Browsing the mailing list I can see that the behaviour of -j with
