On 25/12/2024 15:24, Michael Stone wrote:
On Wed, Dec 25, 2024 at 12:27:16PM +0100, Helmut Grohne wrote:
What do you think about this approach?
There's zero chance I'll carry this as a debian-specific fork of nproc.
(Because I don't want to carry any new forks of the core utilities as
doing so inevitably causes long-term pain.) If you can convince
upstream, that's fine. My personal feeling is that nproc isn't the right
place for it but I'll defer to upstream[1]. (Among other things I don't
understand why this is better than extending the debian tooling in this
area, and there's nothing but an assertion that doing so is bad; I'd
suggest expanding on that.)
[1] My gut says that what you really need is a different tool to show
the memory available to the current process (which may not be the same
as the amount of free memory on the system, e.g., in the presence of
control groups). You could then divide that number by the expected
memory per process and set your parallelization factor to the lesser of
that value or nprocs. Conflating "nproc" and "nmem" seems wrong.
With my upstream hat on, coupling memory details in nproc
seems like not a good fit and better done outside that tool.
Note you can already control the min/max of nproc with
‘OMP_NUM_THREADS’ and ‘OMP_THREAD_LIMIT’ env vars respectively.
cheers,
Pádraig
