All tests should be SMP-safe #14639
Assignees
Labels
area: SMP
Symmetric multiprocessing
area: Tests
Issues related to a particular existing or missing test
Enhancement
Changes/Updates/Additions to existing features
Milestone
Comments
|
Hope we can get a real platform supporting SMP, not just only QEMU. |
andyross
pushed a commit
to andyross/zephyr
that referenced
this issue
Apr 4, 2019
This test was having trouble earlier (at least with some toolchains), but whatever was causing that seems to have been fixed. The only remaining issue is that neither the IPM console code nor the test are SMP-safe. There's a bug (zephyrproject-rtos#14639) tracking the need to get these working, but for now the straightforward workaround is just to disable SMP. And even long term, IPM is an oddball interprocessor communication mechanism designed for asymmetric multiprocessing devices like Quark SE and doesn't seem like an obvious fit for a SMP machine. Fixes zephyrproject-rtos#12478 Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was referenced Apr 4, 2019
nashif
pushed a commit
that referenced
this issue
Apr 5, 2019
This test was having trouble earlier (at least with some toolchains), but whatever was causing that seems to have been fixed. The only remaining issue is that neither the IPM console code nor the test are SMP-safe. There's a bug (#14639) tracking the need to get these working, but for now the straightforward workaround is just to disable SMP. And even long term, IPM is an oddball interprocessor communication mechanism designed for asymmetric multiprocessing devices like Quark SE and doesn't seem like an obvious fit for a SMP machine. Fixes #12478 Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
aescolar
added
the
area: Tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Traditionally, Zephyr was a uniprocessor system. But it now has a SMP platform in CI.
Lots and lots of code in our tests was written to assume uniprocessor behavior, for example that lower priority threads will never run if a higher priority thread is runnable (now it can run on another CPU), or that a given thread mode event will never happen until after the return of a interrupt context event like a timeout (the other CPU can wake up before the ISR returns).
So lots and lots of our test code doesn't run correctly or reliably in SMP right now. It should.
Obviously it won't be possible in all cases to change the designs of the tests (for example: sched/preempt is 100% predicated on the idea of testing two threads against each other on one CPU) but they should be isolated/understood and treated with a code-level workaround (e.g. put a known high priority thread on the other CPU and have it spin during a single-CPU test, or use the thread affinity API, or add extra synchronization layers to prevent events from getting ahead of themselves, etc...).
For 1.15, all test code should be running with default SMP settings unless it is explicitly testing for CONFIG_SMP-specific behavior.
The text was updated successfully, but these errors were encountered: