Round-robing/timesliced tasks disturbed by rate-monotonic task
gedare at rtems.org
Tue Jun 19 21:02:53 UTC 2012
On Tue, Jun 19, 2012 at 4:08 PM, Wendell Silva <silvawp at gmail.com> wrote:
> Hello RTEMS Gurus!
> - RTEMS 4.10.2
> - BSP i386/pc386
> - ticks per timeslice = 5
> - milliseconds per tick = 5
> - Task A, PREEMPT | TIMESLICE, priority = 10, "number crusher" never yield
> CPU voluntarily.
> - Task B, PREEMPT | TIMESLICE, priority = 10, "number crusher" never yield
> CPU voluntarily.
> - Task C, PREEMPT | NO_TIMESLECE, priority = 5, periodic (rate-monotonic),
> period = 5 ticks (25ms), CPU usage = ~50%
> What was expected:
> - Task C running periodically, as programmed.
> - Tasks A and A, using the remaining CPU budget, (~25% each one, in this
> What was observed:
> - Task C running periodically, as programmed (passed).
> - Only task A is running.
> - Task B never runs.
> "Workarounds" applied to achieve the expected behavior:
> - 1: decrease ticks per timeslice; or,
> - 2: decrease task C CPU budget (larger period or less computations).
> I believe the general form of the problem is equivalent to answer:
> - Why timesliced tasks gets starved, when:
> * ticks per timeslice is equals to a period of a RM task, or
> * when the CPU use of RM task is greater than or equals to 50%.
> Is the RM scheduling police interfering in timeslice accounting?
Yes. I have some idea of what is happening.
1. C executes for ~3 ticks.
2. A executes for 2 ticks, has budget=3 remaining when C fires.
3. C executes for 3 ticks; then _Thread_Dispatch sees A as heir and
replenishes A's timeslice
4. A executes for 2 ticks, has budget=3 remaining when C fires
5. goto 3
The RM task is scheduled by a watchdog timer that fires during the
rtems clock_tick, but has no particular knowledge about the tasks that
are time-sliced. So when the RM task finishes its period, it
dispatches back to the thread it interrupted and replenishes that
task's budget without making any other checks.
I don't know if this behavior is a bug. To obtain the behavior you
desire you could augment _Thread_Dispatch to check if the
heir->cpu_time_budget == 0 before replenishing it if changing RTEMS
internally is an option for you. If not then you have to do some
finagling with the task parameters as you indicated, or submit a bug
report and convince someone that the behavior described here is a bug
and should be fixed and back-ported. :)
If you can hook up to a debugger you can 'break' at _Thread_Dispatch
(or rtems_clock_tick) and check what the values are for
_Thread_Executing and _Thread_Heir and their cpu_time_budget (if
either is timeslicing) to verify the behavior I described.
> Test program attached.
> Run with:
> - qemu-system-i386 -kernel Debug/exer_rm
> (it what tested in a real hardware and the same behavior was observed).
> Change system.h and/or task_four to "fix".
> Best regards,
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users