size thread pools by the cores we are allowed, not the ones the host has

std::thread::hardware_concurrency() reports the MACHINE's core count. Inside a
container that is the wrong number: with --cpuset-cpus 0-5 on a 12-core host it
still answers 12, and every caller that sized a pool from it oversubscribed 2x.

Measured on the pool box:
  - the pool node logged "Mining with 11 thread(s) of 12 core(s)" while
    confined to 6 CPUs
  - a burst miner launched with /hashthreads=2 filled the ~2 GB RandomX
    dataset with 12 threads, alongside the pool node in the same 8 GB container

AvailableCoreCount() asks sched_getaffinity what the cpuset actually permits,
which is the number all of these meant. It cannot make the dataset build slower:
the CPU budget is identical either way, so fewer threads on the same cores is
the same work without the thrash. Falls back to hardware_concurrency where the
call is unavailable, and never returns 0 because callers subtract from it.

Not the cause of the burst miner dying -- that was a corrupt Berkeley DB
environment in the worker datadir -- but it is why the failure landed on the
dataset build, and it is wrong on its own terms.

(cherry picked from commit b3bee16f3eef8982bff1174bd9d0a9c21473732c)

1 files changed, 1 insertions, 1 deletions

diff --git a/src/net.cpp b/src/net.cpp
index 77f9acf..72a7fda 100644
--- a/src/net.cpp
+++ b/src/net.cpp
@@ -1910,7 +1910,7 @@ int StartMinerThreads()
     // question anyone asks.
     printf("Mining with %d thread(s) of %u core(s) -- about %d MB "
            "(~2080 MB shared RandomX dataset + ~2 MB per thread)\n",
-           nStarted, std::thread::hardware_concurrency(), 2080 + 2 * nStarted);
+           nStarted, AvailableCoreCount(), 2080 + 2 * nStarted);
     return nStarted;
 }