tests: z_test_1cpu_start() makes only CPU0 active #70579
Merged
Conversation
This file contains 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
zephyrbot
requested review from
aaronemassey,
asemjonovs,
jeremybettis,
nashif and
yperess
|
@peter-mitsis does not seem ot solve the issue. Running on |
|
That is unfortunate. Digging a little more into this one. |
When z_test_1cpu_start() is called to ensure that only a single CPU on an SMP system is available for use in a test, this commit will ensure that that CPU is the primary CPU--CPU0. This is done because some timer drivers only have the timer interrupt processed by one CPU. A bit of a song and dance is performed to achieve this without enabling the CPU mask/affinity pinning API. If the cpuhold thread is found to be executing on CPU0, then a new copy of cpuhold thread is created. Once the new copy is executing (incidentally guaranteed to be on another CPU) then it informs the original copy and busy waits until it the original copy is switched out of CPU0. At this point, we can create the next cpuhold thread to occupy another CPU if needed. During this song and dance, it is critical that the 'copy' not pend. If it pends, we can not guarantee which CPU it will execute on when it unpends. As the cpuhold threads have the highest priority, nothing is going to cause them to execute on another CPU for as long as they do not pend. Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
peter-mitsis
force-pushed
the
pmitsis-ztest-1cpu-fix
branch
from
0b440f5
to
7af2918
Compare
|
Found the issue with the previous version. I was tagging the wrong thread resource as used so the 2nd time it found that the cpu_hold thread was on CPU0, it reused an existing k_thread--hijinks ensued. This one should work. |
nashif
approved these changes
Mar 23, 2024
dcpleung
approved these changes
Mar 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When z_test_1cpu_start() is called to ensure that only a single CPU on an SMP system is available for use in a test, this commit will ensure that that CPU is the primary CPU--CPU0. This is done because some timer drivers only have the timer interrupt processed by one CPU.
A bit of a song and dance is performed to achieve this without enabling the CPU mask/affinity pinning API. If the cpuhold thread is found to be executing on CPU0, then a new copy of cpuhold thread is created. Once the new copy is executing (incidentally guaranteed to be on another CPU) then it informs the original copy and busy waits until it the original copy is switched out of CPU0. At this point, we can create the next cpuhold thread to occupy another CPU if needed.
During this song and dance, it is critical that the 'copy' not pend. If it pends, we can not guarantee which CPU it will execute on when it unpends. As the cpuhold threads have the highest priority, nothing is going to cause them to execute on another CPU for as long as they do not pend.
Fixes #70494