0875740a34
This test is a little subtle: it wants to spawn three threads to run and be switched out by a timeslice interrupt. And it wants to consume half a time slice itself before it starts running. And, because timeslicing runs out of the same tick framework in the timer driver, it needs to align to the start of a tick before the process starts. And further: it does its own time math not in ticks but in timer cycles, so it's quite sensitive to slop. But it's "synchronize to tick boundary" code was actually synchronizing to a CYCLE boundary, which is just wrong. And it was doing this in the wrong order. It was resetting the timeslice first and then synchronizing to a tick by spinning, which means that the test was always going to begin as much as a tick late. Do the tick synchronization (via a sleep) first. Finally, the manager thread that was spawning the new threads lives at the same priority as the highest priority child threads, which means it can potentitially wake up on the semaphores that they are giving in the middle of the test and consume CPU unexpectedly. Make sure it's sleeping for the duration. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| deadline | ||
| metairq | ||
| preempt | ||
| schedule_api | ||