Maybe this should be a loky issue instead?

Summary

joblib.cpu_count(only_physical_cores=True) appears to count logical CPUs rather than physical cores when the process is restricted with CPU affinity (taskset).

This is surprising on Linux when the affinity mask includes SMT siblings from the same physical core. In that case, only_physical_cores=True returns the same value as only_physical_cores=False.

Reproducer

On a Linux machine where CPUs 0 and 1 are SMT siblings of the same physical core:

cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
# 0-1

taskset -c 0,1 python - <<'PY'
from joblib import cpu_count

print(cpu_count(only_physical_cores=True))
print(cpu_count(only_physical_cores=False))
PY

Observed output:

2
2

Expected output, or at least the behavior I expected from only_physical_cores=True:

1
2

Context

I noticed this while using taskset to run scaling benchmarks, I wanted to preserve the topology of cores, i.e. I wanted that "running one core" means taskset -c 0,1 (one physical core, 2 logical cpus). But if I do that sklearn/joblib will detect two physical cores and run with two threads instead of one.

I saw in loky's cpu_count implementation that only_physical_cores=True is not enforced when the usable CPU count is constrained by affinity or other user constraints. That might make this documented/expected behavior, but I'd say we still want to collapse the affinity mask through Linux topology information when available (for only_physical_cores=True).