Timeslice issues with preemption enabled

[wangqiang3 at sugon.com]

Thank you for your reply!

To Kuan-Hsun Chen:
This is my test eviroment and test case:
Test eviroment:
rtems-bsp: arm/xilinx_zynq_a9_qemu
rtems version: 5.1

Test case:
#include <rtems.h>
#include <stdlib.h>
#include <stdio.h>

rtems_id Task[3];

static void taskRunner(rtems_task_argument arg)
{
    while(1)
    {
        if (arg == 2)
        {
            rtems_task_wake_after(1);
        }
        printk("task TST%d running\n",arg);
    }
}

rtems_task Init(
        rtems_task_argument ignored
        )
{
    rtems_status_code ret = rtems_task_create(rtems_build_name('T', 'S', 
'T', '0'), 128, RTEMS_MINIMUM_STACK_SIZE,
                 RTEMS_TIMESLICE | RTEMS_PREEMPT  , RTEMS_LOCAL, 
&Task[0]);
    ret = rtems_task_create(rtems_build_name('T', 'S', 'T', '1'), 128, 
RTEMS_MINIMUM_STACK_SIZE,
                 RTEMS_TIMESLICE | RTEMS_PREEMPT , RTEMS_LOCAL, &Task[1]);
    ret = rtems_task_create(rtems_build_name('T', 'S', 'T', '2'), 2, 
RTEMS_MINIMUM_STACK_SIZE,
                RTEMS_TIMESLICE | RTEMS_PREEMPT , RTEMS_LOCAL, &Task[2]);

    ret = rtems_task_start(Task[0], taskRunner,0);
    ret = rtems_task_start(Task[1], taskRunner,1);
    ret = rtems_task_start(Task[2], taskRunner,2);

    rtems_task_exit();
}

To Gedare Bloom:
It works only when pthread_setschedparam() with SCHED_RR was called after 
rtems_task_start().
And when call rtems_task_mode() or rtems_task_restart(), the same problem 
will appears again, seems that SCHED_RR flag was cleaned away.

Regards
Wang

"Gedare Bloom" <gedare at rtems.org> 2021/06/10 22:24:51:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210615/a8a4cae2/attachment-0001.html>