macOS: thread affinity handling (no-op guard + QoS performance-core hint) - #3035
Open
tomjn wants to merge 1 commit into
Open
macOS: thread affinity handling (no-op guard + QoS performance-core hint)#3035tomjn wants to merge 1 commit into
tomjn wants to merge 1 commit into
Conversation
…int) macOS / Apple Silicon has no portable per-thread CPU affinity API (no sched_*/cpu_set_t, and Mach's THREAD_AFFINITY_POLICY is a no-op on Apple Silicon). Handle this in two places: - ThreadAffinityGuard: no-op on macOS. affinitySaved stays false so the destructor's restore is skipped. Kept minimal -- no extra members or includes, existing comments preserved. - Threading::SetAffinity: instead of a hard affinity mask, apply a QoS hint (QOS_CLASS_USER_INTERACTIVE) which biases the scheduler toward the performance cores and away from the efficiency cores. The specific coreMask can't be honored, so the affinity is reported as "not set" (~0) and final placement is left to the scheduler. This is a "prefer performance cores" hint, not a hard pin (which Apple Silicon does not offer). Cross-platform-safe: Windows/Linux unchanged, FreeBSD/OpenBSD keep their existing affinity no-op.
tomjn
changed the title
tomjn
force-pushed
the
mac/thread-affinity-guard-stub
branch
from
June 20, 2026 00:03
8549657 to
ad16282
Compare
sprunk
approved these changes
Jun 20, 2026
sprunk
left a comment
sprunk
left a comment
Collaborator
There was a problem hiding this comment.
LGTM but @lostsquirrel1 should probably take a look just in case.
Contributor
Author
|
Some related changes to go with this in #3036 |
This was referenced Jul 27, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
macOS thread-affinity handling, in the two places the engine touches affinity. macOS / Apple Silicon has no portable per-thread CPU affinity API — no
sched_*/cpu_set_t, and Mach'sTHREAD_AFFINITY_POLICYis a no-op on Apple Silicon — so neither hard pinning nor save/restore is possible.1.
ThreadAffinityGuard→ no-op on macOSaffinitySavedstaysfalse(its constructor default), so the destructor's restore is skipped, and thecpu_set_t/sched_*code is excluded from the macOS compile. Kept deliberately minimal: no placeholder member, no extra includes, and the existing cross-platform comments are left intact.2.
Threading::SetAffinity→ QoS "prefer performance cores" hintInstead of a hard affinity mask, macOS applies
pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0), which biases the scheduler toward the performance cores and away from the efficiency cores. The specificcoreMaskcan't be honored, so the affinity is reported as "not set" (~0) and final placement is left to the scheduler.Scope / intent
This is a prefer, not a force — hard pinning to specific cores doesn't exist on Apple Silicon, so QoS is the strongest available lever, and the scheduler retains the final say. Accurate P/E-core sizing of the worker pool (e.g. via
hw.perflevel0.physicalcpu) is a separate, later concern and not needed for this hint.Cross-platform safety
Purely additive on the macOS path. Windows and Linux are unchanged; FreeBSD/OpenBSD keep their existing affinity no-op. The
__APPLE__branch was split out of the previous__APPLE__ || __FreeBSD__ || __OpenBSD__group so only macOS pulls in<pthread/qos.h>and the QoS call.Extracted/adapted from the macOS bring-up (#2991) as a standalone, reviewable piece.