Skip to content

Conversation

@angelcerveraroldan
Copy link
Contributor

Add an option for external tests to be executed by a machine with multiple numa nodes.

@openshift-ci
Copy link

openshift-ci bot commented Feb 3, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces the capability to simulate NUMA nodes in QEMU for external tests. The changes involve adding a NumaNodes option and plumbing it through various layers of the test harness and platform configuration. The core logic for generating QEMU arguments for NUMA is in mantle/platform/qemu.go.

I've identified a couple of issues in the implementation within mantle/platform/qemu.go that could lead to incorrect resource allocation for the simulated NUMA nodes. My review includes suggestions to fix these bugs.

Timeout time.Duration // the duration for which a test will be allowed to run
RequiredTag string // if specified, test is filtered by default unless tag is provided -- defaults to none
Description string // test description
NumaNodes int // Number of numa nodes to simulate
Copy link
Member

Choose a reason for hiding this comment

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

Should we make this an on/off flag where we hardcode 2 NUMA nodes as I don't think we'll test with more than that and maybe that should simplify the code a bit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this remove the for loop in baseNumaQemuArgs function, but most of the checks would still be quite similar.

Would it be useful to also allow the numaNodes flag with the cosa run command for debugging? If so, allowing an integer may be nice.

If making it a boolean would keep it simpler, and the above is not worth implementing, then I am happy to change it to use a boolean flag.

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.

2 participants