Skip to content

test(libc): run cpu_topology on Windows - #9584

Open
DavidSamir wants to merge 2 commits into
boykopovar:mainfrom
DavidSamir:test/win-cpu-topology
Open

DavidSamir wants to merge 2 commits into
boykopovar:mainfrom
DavidSamir:test/win-cpu-topology

Conversation

@DavidSamir

@DavidSamir DavidSamir commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

What

cpu_topology was registered only on Linux (libc/CMakeLists.txt:912). CpuTopology::Get and Pin also have Windows paths, which no test ran: GetProcessAffinityMask, LayoutFromClasses over GetLogicalProcessorInformationEx efficiency classes, and SetThreadAffinityMask.

How:

  • libc/CMakeLists.txt: the guard becomes Linux OR WIN32. macOS stays excluded because Get/Pin have no macOS path. The libc link, configure_windows_unwind and the PATH prepend apply on WIN32 only, so the Linux build is unchanged.
  • CpuTopology.cpp: the sysfs MaskFromCpuList checks move under #ifdef __linux__, since that function is Linux-only. On Windows the pinned mask is read back with SetThreadAffinityMask, which returns the mask it replaces. Pinning by thread handle is also checked, because the Windows Pin honours handles. The Linux checks are unchanged.

Tested

  • Windows 11 Pro 26200, WinLibs GCC 15.2.0, Release. CPU-side only, no GPU involved. ctest -R ^cpu_topology$ passes.
  • Negative control: with GetProcessAffinityMask in Get() disabled, the test fails with "process affinity read". Restored, it passes.
  • tools/check_conventions.py passes.

Overlap (tools/pr_overlap.py --branch plus git merge-tree):

Checklist

  • Based on current main; no other open PR implements the same functions
  • One topic per PR; follow-ups go in a new PR
  • No comments in code except technical debt
  • Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
  • No notes, investigation .md files or images added to the repository (attach them to this PR)
  • New third-party code is a submodule built from source
  • Generic behaviour, not specific to one title
  • Depends on: none
  • Fixes: none
  • Unblocks: none
  • GPUs tested: n/a
  • AI-assisted: yes

CpuTopology::Get and Pin have Windows paths (GetProcessAffinityMask,
GetLogicalProcessorInformationEx efficiency classes, SetThreadAffinityMask)
that no test ran. The test now builds on Windows too: the sysfs cpu-list
parser checks stay Linux-only, the pinned mask is read back with
SetThreadAffinityMask, and pinning by thread handle is checked.
@github-actions

github-actions Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request Conflicting files (lines on main) Same exports Same new files
PR 14298 core/libs/prx/libc/CMakeLists.txt L1404

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request Shared files not compared
PR 5021 core/libs/prx/libc/CMakeLists.txt
PR 6819 core/libs/prx/libc/CMakeLists.txt
PR 7081 core/libs/prx/libc/CMakeLists.txt
PR 7447 core/libs/prx/libc/CMakeLists.txt
PR 7715 core/libs/prx/libc/CMakeLists.txt
PR 8150 core/libs/prx/libc/CMakeLists.txt
PR 8965 core/libs/prx/libc/CMakeLists.txt
PR 9929 core/libs/prx/libc/CMakeLists.txt
PR 11831 core/libs/prx/libc/CMakeLists.txt
PR 12682 core/libs/prx/libc/CMakeLists.txt
PR 12688 core/libs/prx/libc/CMakeLists.txt
PR 12700 core/libs/prx/libc/CMakeLists.txt
PR 12965 core/libs/prx/libc/CMakeLists.txt
PR 13390 core/libs/prx/libc/CMakeLists.txt
PR 14585 core/libs/prx/libc/CMakeLists.txt

@MarcZX10 MarcZX10 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Windows assertions exercise process-mask filtering, current-thread pinning and the thread-handle path; the implementation changes shown in the PR leave the Linux assertions under their original platform guard. The latest conventions check passes, superseding the earlier template-check failure. Hosted relinker, register-context and write-watch checks pass; product build jobs are skipped. The Windows test result is author-reported; I did not run it locally.

The unresolved manual overlap with #6044 is specifically the moved CpuTopology.cpp, not just the shared CMake insertion. #6044 renames the Linux test to core/libs/tests/process/CpuTopology.cpp without changing its contents; this PR adds the Windows branch to the original path. Please coordinate with #6044's author so the Windows additions follow the file to its renamed path if #6044 lands first, and record the agreed order/dependency if one must land first. The PR's statement that merge-tree followed the rename should be reconciled with the overlap bot's explicit inability to compare the test path.

Please also update the test path/registration if the reorganization lands first; keeping the new Windows-only coverage on the unregistered old filename would drop it from CI.

@fogydes

fogydes commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

The Conventions check fails on the head of this PR (job 119621777041: Fill in the pull request template: section 'What' is missing or empty, and the same for Tested and Checklist).

Everything else in the matrix is green (relinker on all three OSes, relinker-asan, register-context, write-watch), and python3 tools/check_conventions.py --base origin/main prints the same three template findings locally. Filling in every line of .github/pull_request_template.md (What, Tested, Depends on, Unblocks, GPUs tested, AI-assisted, and tick the boxes) is all that appears to block CI.

@DavidSamir

Copy link
Copy Markdown
Contributor Author

@fogydes thanks. That was the first head; the template was filled in and the Conventions job on the current head passes. For #6044 I've proposed the order on that PR (the Windows additions follow CpuTopology.cpp to tests/process/ if #6044 lands first) and am waiting for its author.

AI-assisted: yes

@MarcZX10 MarcZX10 left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes keep Linux behavior under the Linux guards and add Windows checks for process affinity, class layout, current-thread pinning and handle-based pinning. I also compiled the exact core/libs/tests/CpuTopology.cpp with GCC 12.2 (-std=c++20 -Wall -Wextra -Werror) and ran it standalone on Linux; it passed. This checks the shared/Linux path, not the new Windows-only assertions. The Windows 11 run and negative control in the PR description remain author-reported. One repository gate remains: 1. #6044 coordination: thank you for proposing on #6044 that the Windows cases follow CpuTopology.cpp to tests/process/ if its rename lands first. I do not see an agreement from that PR's author yet. Please wait for agreement and record the agreed merge order in the checklist (Depends on if this PR must wait), then carry the Windows cases and registration to the renamed path as needed. The overlap workflow cannot compare the shared files while #6044 conflicts with main. This head is 107 commits behind current upstream/main; please update it after the #6044 order is settled and rerun the checks. Checks on exact head 46c665015223ad582a26e90768b2c0f9dfd7b0e0: - git diff --check upstream/main...HEAD: passed. - python tools/check_conventions.py --base upstream/main --head HEAD: passed. - Standalone Linux test-source compile/run: passed (GCC 12.2; this does not test the Windows branch). - Hosted eligibility, conventions, labels, report, relinker matrix, ASan, register-context and write-watch checks pass; Linux/Windows product jobs are skipped. I am requesting changes for unresolved overlap agreement and base freshness only, not a queue-based intake hold or a defect in the added test logic. It is fine to keep submitting PRs; maintainers will handle them in due course.

I’ve noticed that holding this PR because of #5239 isn’t necessary. It’s fine for PRs to keep coming in; they’ll be handled in due course. Please disregard my earlier request to hold or defer it.

@JJenkx

JJenkx commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

Independent Windows run, as data only. Machine: Windows 11 Enterprise 10.0.22621, AMD Ryzen 9 5950X (16 cores, 32 logical processors), WinLibs GCC 15.2.0 UCRT r7, Release. Head 46c6650 was merged with #9583 onto main 8b3a6ba. cpu_topology passes in 10 of 10 runs. (guest_fopen_errors from #9583 is a separate issue, reported there.)

AI-assisted (Claude Code).

@MarcZX10

MarcZX10 commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

The remaining review items are #6044 coordination and current-base freshness. I still do not see a reply from #6044’s author to your proposed ordering for moving the Windows test registration. This head is 150 commits behind current upstream/main 8b3e39832af85f404c6195418d11b3e1ebd1924d; current-main git diff --check and conventions pass. I previously compiled and ran the exact CpuTopology.cpp test source standalone under GCC 12.2 on Linux; it passed the shared/Linux path, but does not exercise Windows assertions. The author and independent Windows reports show the Windows test and negative control passing, and hosted non-product matrices pass; product jobs are skipped. Please record the agreed #6044 order and refresh to current main before final validation. I found no behavior defect in the test additions.

@MarcZX10

Copy link
Copy Markdown
Contributor

I’ve noticed that asking you to hold this PR was unnecessary. It’s fine to keep submitting PRs; maintainers will handle them in due course.

@THEMANnt THEMANnt left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 46c665015223ad582a26e90768b2c0f9dfd7b0e0 against 6ef5a1c4c92272598b18adeb9b5414112f8d15ed. No actionable findings in this focused review.

Source review: Inspected the complete registration/test change and CpuTopology's header-only implementation. Linux list parsing stays Linux-only. Windows checks compare SetThreadAffinityMask's previous-mask return value after Pin, reject masks outside the process and verify handle-based pinning. The CMake branch adds the Windows runtime/unwind setup and PATH consistently with neighboring native tests.

Validation: Windows / MinGW GCC 15.2: built the exact head CpuTopology.cpp against its pinned headers and ran it successfully (exit 0). Its runtime changes are confined to that test child. Baseline Windows compilation fails at the former unconditional Linux affinity APIs, demonstrating the portability change. Conventions, whitespace and script registration passed. Current hosted relinker/ASan and metadata checks succeeded; product Windows/Linux jobs were skipped.

Scope: Actual header-only CPU topology test on this Windows host; the full libc-linked CMake target and Linux runtime were not rebuilt/run locally. No game or GPU test.

@blawesom

Copy link
Copy Markdown
Contributor

Static review plus an independent Linux run (CachyOS, kernel 7.2.10, GCC 16.2.1, Ninja, Release, BUILD_TESTING=ON, Ryzen 7 9800X3D). No findings.

What I checked (static)

  • The Linux-only mask-parsing tests (Parse via temp-file → CpuTopology::MaskFromCpuList) are correctly scoped #ifdef __linux__ — they exercise a /proc-style cpulist format that doesn't exist on Windows, so excluding them there is right, not a coverage hole.
  • The generic class/hybrid asserts (byClass, performant/efficient disjointness, process mask) run on both hosts unchanged — those are host-agnostic.
  • The Windows branch's new asserts are the interesting part: they verify CpuTopology::Pin(nullptr, first) actually lands the caller's thread (SetThreadAffinityMask(GetCurrentThread(), first) == first), that a mask outside the process mask returns 0 without applying, and that handle-based pinning threads by GetCurrentThread() and by full layout.process both take effect — confirmed by re-reading SetThreadAffinityMask against the expected previous mask afterwards. That mirrors exactly what the #else branch asserts with pthread_getaffinity_np, so the two hosts pin the same invariants via their native API.
  • CMake block grows only on WIN32 (target_link_libraries(libc), configure_windows_unwind, PATH prepend) — matching the sibling guest_backtrace_tests registration right below.

Focused test run

tree result
this head 46c6650152 1/1 cpu_topology Passed (0.00s)

Not an AGC/shader/VideoOut change — no paired Vulkan-validation run required.

Not covered

The new Windows-only asserts (#ifdef _WIN32) compile correct-by-inspection but were not executed here (Linux host). Worth confirming on the Windows CI leg before merge if that's cheap.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants