From 88d30ade28d6836e64d0157da57896bdb320e8a2 Mon Sep 17 00:00:00 2001 From: bitflash-maintainer Date: Thu, 13 Aug 2026 17:29:10 +0000 Subject: 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) --- src/main_gui.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/main_gui.cpp') diff --git a/src/main_gui.cpp b/src/main_gui.cpp index c20ae46..bee4b95 100644 --- a/src/main_gui.cpp +++ b/src/main_gui.cpp @@ -202,7 +202,7 @@ static void ParseStartupArguments(int argc, char* argv[]) if (!strProcLimit.empty()) { int n = atoi(strProcLimit.c_str()); - unsigned int nCores = std::thread::hardware_concurrency(); + unsigned int nCores = AvailableCoreCount(); if (n < 0) fprintf(stderr, "Ignoring /genproclimit=%s: not a thread count\n", strProcLimit.c_str()); -- cgit v1.2.3