Timeslice issues with preemption enabled

[Gedare Bloom]

On Thu, Jun 10, 2021 at 4:10 AM Kuan-Hsun Chen <c0066c at gmail.com> wrote:
>
> Hello,
>
> If that is the case, I think we should probably first agree on, what is the preferred behavior under the circumstance. I think picking heir tasks always in the same order is a proper design, but the preemption should not corrupt the "fair" time slicing in my opinion (so follow what you observe). From what I can find in the documents or source code, e.g.,
>
> https://docs.rtems.org/branches/master/c-user/task/background.html?highlight=slice#task-priority (the latest version)
> https://docs.rtems.org/releases/rtemsdocs-4.6.2/share/rtems/html/c_user/c_user00303.html (old version)
> https://github.com/RTEMS/rtems/blob/master/cpukit/include/rtems/rtems/tasks.h
>
> There is no definition or clarification about the problem you mentioned. To answer some of your questions:
>
> I think there is no WHY, but this probably can be patched if we deem it as a problem.
> Timeslicing in RTOS usually follows a round-robin manner according to an given order. To have a determinate behavior, I think it makes sense that it always pick Task B as heir task.
>
> Could you provide your testing code so that we can repeat the same scenario? I would like to give a try as well.
>
> Best regards,
> Kuan-Hsun
>
>
> On Thu, Jun 10, 2021 at 11:25 AM <wangqiang3 at sugon.com> wrote:
>>
>> Description of the issue：
>> I created three tasks, Task A, Task B and Task C. All tasks are based on RTEMS_TIMESLICE | RTEMS_PREEMPT , Task A has a higher priority than other tasks, Task B has the same priority as Task C.
>> Tasks B and C loop forever, Task A sleeps 1 TICK on an endless loop. When I test, I find that task C is not scheduled.
>>
>> Hope result:
>> I was expecting tasks A, B, and C to be scheduled. Task A can preempt task B and C. Tasks B and C can switch to each other when the time slice runs out.
>>
>> Actual result:
>> When task A preempts task B and run out its timeslice, then switch to task B, task B's timeslice will reset to _Watchdog_Ticks_per_timeslice.
>> While the task B is still running, Task A preempts task B again. Task A will pick up task B as heir task and reset task B's timeslice.
>> This will cause task C never be scheduled.
>>
>> My doubts ：
>> 1. Why must reset the time slice every time when switch tasks.
Because THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE is set.

>> 2. Why the scheduler only pick up Task B as heir task?
The timeslice never exhausts, and the task never yields.

>> 3. Can I comment the following code in _Thread_Do_dispatch()? Is there any problem if I change it this way?
>>     if ( heir->budget_algorithm == THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE )
>>         heir->cpu_time_budget = rtems_configuration_get_ticks_per_timeslice();

No, this breaks THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE

>> 4. I found that only in POSIX can I use the algorithm THREAD_CPU_BUDGET_ALGORITHM_EXHAUST_TIMESLICE , RTEMS classics api only can use THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE.
>>    Can I use THREAD_CPU_BUDGET_ALGORITHM_EXHAUST_TIMESLICE in RTEMS classics api.nd rtems_task_mode.
>> 5. Can anyone give some suggestions to solve the problem? thanks!

Classic and POSIX APIs can be mixed. It is a poorly documented benefit
of RTEMS. I think in this case, you should be able to use
pthread_setschedparam(...) with passing policy == SCHED_RR to get the
behavior you seek. You have to use posix priorities in the sched_param
argument. though, or else your thread will have its priority changed.
Pass the task_id instead of pthread_t as the first argument, and the
rest should work itself out. Do let us know if that works or it
doesn't work/you have more questions.

Gedare

>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>> --
>> Diese Mail wurde mobil geschrieben. Etwaige Rechtschreibfehler sind volle Absicht und als großzügiges Geschenk zu verstehen.
>>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users