Hi,

> Before we move on, please allow me to ask what problem the nproc tool is
> supposed to solve. Of course it tells you the number of processors, but
> that is not a use case on its own. If you search for uses, "make
> -j$(nproc)" (with varying build systems) is the immediate hit.  This use
> is now broken by hardware trends (see below). It can also be used to
> partition a system and computing partition sizes. This use case
> continues to work.  Are there other use cases? Unless I am missing
> something, it seems like nproc no longer solves its most common use case
> (and this bug is asking to fix it).
>
> Thus far, I am effectively turned down by:
>  * coreutils
>  * debhelper
>  * dpkg
>
> What other place would be suitable for including this functionality? We

Thanks Helmut for trying to solve this. I rely on nproc in all my
packages to instruct Make on how many parallel build processes to run,
and I have repeatedly run into the issue that on large hardware with
16+ cores available, builds tend to crash on memory issues unless
there is also at least 2GB of physical RAM on the system per core. The
man page of nproc says its purpose is to "print the number of
processing units available" so I too would have assumed that adding a
memory cap would fit nproc best. Man page of nproc also already has
the concept of "offline cpu" for other reasons. Creating a new tool
just for this seems like a lot of overhead.

Reply via email to