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, 8 insertions, 4 deletions

diff --git a/src/main.cpp b/src/main.cpp
index 11eb11d..62068d2 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -164,7 +164,7 @@ int MinerThreadCount()
 {
     if (nMinerThreads > 0)
         return nMinerThreads;
-    unsigned int nCores = std::thread::hardware_concurrency();
+    unsigned int nCores = AvailableCoreCount();
     if (nCores <= 1)
         return 1;
     return (int)(nCores - 1);
@@ -3827,7 +3827,11 @@ connected:
     // ------------------------------------------------------------------
     if (!RandomXFastReady()) {
         SetParticipantMiningStatus("building RandomX dataset (~2GB, one-time)");
-        unsigned int nThreads = std::thread::hardware_concurrency();
+        // Fill with the cores we are permitted to use, not the ones the host
+        // happens to have. More threads than the cpuset allows does not build
+        // the dataset any faster -- the CPU budget is the same either way --
+        // it just oversubscribes, and this runs alongside the pool node.
+        unsigned int nThreads = AvailableCoreCount();
         RandomXInitDataset(nThreads > 0 ? (int)nThreads : 1);
     }
     LogPrint("worker", "[worker] RandomX dataset ready (%s)\n",
@@ -3866,7 +3870,7 @@ connected:
     // publish jobs to the threads, submit the shares they find.
     // ------------------------------------------------------------------
     int nWorkers = nHashThreads > 0 ? nHashThreads
-                                    : (int)std::thread::hardware_concurrency();
+                                    : (int)AvailableCoreCount();
     if (nHashThreads <= 0) {
         if (nWorkers < 2) nWorkers = 2;
         nWorkers -= 1; // leave one core for node + I/O threads
@@ -4177,7 +4181,7 @@ bool BitcoinMiner(int nThreadId)
     // Build the fast (~2 GB dataset) RandomX mode once, up front, so we're
     // not stuck mining in the much slower light/cache-only mode forever.
     if (!RandomXFastReady()) {
-        unsigned int nThreads = std::thread::hardware_concurrency();
+        unsigned int nThreads = AvailableCoreCount();
         RandomXInitDataset(nThreads > 0 ? (int)nThreads : 1);
     }