commit 3c4955942942bed266537859d1c158f2fa4bef79
parent 8168b31afd40ea603285421d51fa4383f43c8422
Author: Heitor Neiva <hneiva@mozilla.com>
Date: Mon, 3 Nov 2025 19:24:30 +0000
Bug 1996349 - Switch xpcshell tests to highcpu pool r=florian,releng-reviewers,taskgraph-reviewers,ahal
Differential Revision: https://phabricator.services.mozilla.com/D270050
Diffstat:
5 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/taskcluster/config.yml b/taskcluster/config.yml
@@ -725,7 +725,7 @@ workers:
implementation: generic-worker
os: linux-lambda
worker-type: 'gecko-{alias}'
- t-linux-docker(|-noscratch|-noscratch-amd|-amd):
+ t-linux-docker(|-noscratch|-noscratch-amd|-16c32gb-amd|-amd):
provisioner: '{trust-domain}-t'
implementation: docker-worker
os: linux
diff --git a/taskcluster/gecko_taskgraph/transforms/test/__init__.py b/taskcluster/gecko_taskgraph/transforms/test/__init__.py
@@ -135,6 +135,7 @@ test_description_schema = Schema(
"large-noscratch",
"xlarge",
"xlarge-noscratch",
+ "highcpu",
),
),
# type of virtualization or hardware required by test.
diff --git a/taskcluster/gecko_taskgraph/transforms/test/worker.py b/taskcluster/gecko_taskgraph/transforms/test/worker.py
@@ -11,6 +11,7 @@ LINUX_WORKER_TYPES = {
"large-noscratch": "t-linux-docker-noscratch-amd",
"xlarge": "t-linux-docker-amd",
"xlarge-noscratch": "t-linux-docker-noscratch-amd",
+ "highcpu": "t-linux-docker-16c32gb-amd",
"default": "t-linux-docker-noscratch-amd",
}
diff --git a/taskcluster/kinds/test/xpcshell.yml b/taskcluster/kinds/test/xpcshell.yml
@@ -57,7 +57,7 @@ xpcshell:
by-test-platform:
linux.*: large-legacy
default: large
- default: large-noscratch
+ default: highcpu
run-on-projects:
by-variant:
conditioned_profile:
diff --git a/testing/xpcshell/runxpcshelltests.py b/testing/xpcshell/runxpcshelltests.py
@@ -57,19 +57,18 @@ except ImportError:
HARNESS_TIMEOUT = 30
TBPL_RETRY = 4 # defined in mozharness
-# benchmarking on tbpl revealed that this works best for now
-# TODO: This has been evaluated/set many years ago and we might want to
-# benchmark this again.
-# These days with e10s/fission the number of real processes/threads running
-# can be significantly higher, with both consequences on runtime and memory
-# consumption. So be aware that NUM_THREADS is just saying how many tests will
-# be started maximum in parallel and that depending on the tests there is
-# only a weak correlation to the effective number of processes or threads.
-# Be also aware that we can override this value with the threadCount option
-# on the command line to tweak it for a concrete CPU/memory combination.
-NUM_THREADS = int(cpu_count() * 4)
-if sys.platform == "win32":
- NUM_THREADS = int(cpu_count() * 2)
+# Based on recent benchmarking on highcpu pools, this value gives the best
+# balance between runtime and memory usage
+#
+# Note:
+# - NUM_THREADS defines the maximum number of tests that can run in parallel
+# - With e10s/fission enabled, the actual number of underlying processes/threads
+# can be much higher, so memory pressure may vary accordingly
+# - For ASan/TSan variants, the thread count is reduced by half to avoid OOM
+#
+# This value can be overridden via the --threadCount CLI option if adjustments
+# are needed for custom CPU/memory configurations
+NUM_THREADS = int(cpu_count() * 2.5)
EXPECTED_LOG_ACTIONS = set(
[