Round-robing/timesliced tasks disturbed by rate-monotonic task

[Gedare Bloom]

On Tue, Jun 19, 2012 at 4:08 PM, Wendell Silva <silvawp at gmail.com> wrote:
> Hello RTEMS Gurus!
>
> Environment:
>   - RTEMS 4.10.2
>   - BSP i386/pc386
>
> Summary:
>   - 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
> configuration).
>
> 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.

-Gedare

> 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,
>
> --Wendell.
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>