All of lore.kernel.org
 help / color / mirror / Atom feed
* rt_task_set_priority does not increase priority of other task
@ 2020-09-16 18:12 Harco Kuppens
  2020-09-17 11:51 ` Jan Kiszka
       [not found] ` <916ef19a754d4e42b0eaefa8a1a26060@EXPRD08.hosting.ru.nl>
  0 siblings, 2 replies; 9+ messages in thread
From: Harco Kuppens @ 2020-09-16 18:12 UTC (permalink / raw)
  To: Xenomai@xenomai.org


Hi,

I found a problem with rt_task_set_priority function which does not 
increase priority of another task.
However it works fine if you increase the priority of another task.

Below is an en example program and its output, and we run this program 
on xenomai 3.08.
The problem appears if we run the program on our xenomai image for the 
raspberry pi 3,
and is also appears in our virtual box image.
Both images can be found at :

  * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
  * http://www.cs.ru.nl/lab/xenomai/virtualbox.html

The easiest way is to run the virtualbox image.

The final question I have: is there an wrong usage of xenomai API in the 
example program,
or is this a bug in xenomai?

Hope somebody can help me with this problem.

Best regards,
Harco Kuppens

The following xenomai program has the problem:

    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>
    #include <alchemy/task.h>
    #include <alchemy/sem.h>
    #include <alchemy/timer.h>

    #define NTASKS 3
    #define HIGH 52 /* high priority */
    #define MID 51 /* medium priority */
    #define LOW 50  /* low priority */

    RT_TASK demo_task[NTASKS];
    RT_SEM mysync;

    #define EXECTIME   2e8   // execution time in ns
    #define SPINTIME   1e7   // spin time in ns
    #define SLEEPTIME   1e9   // sleep time in ns

    void demo(void *arg)
    {
         int ret;
         RT_TASK *curtask;
         RTIME starttime, runtime;
         RT_TASK_INFO taskinfo;
         int num=*(int *)arg;
         printf("Task  : %d\n",num);
         rt_sem_p(&mysync,TM_INFINITE);


         runtime = 0;
         while(runtime < EXECTIME) {
           rt_timer_spin(SPINTIME);  // spin cpu doing nothing
           runtime = runtime + SPINTIME;

           // inquire current task
           curtask=rt_task_self();
           rt_task_inquire(curtask,&taskinfo);

           printf("Running Task  : %d  prio: %d at ms : %d
    \n",num,(int)taskinfo.prio,(int) runtime/1000000);

           /**
            * Halfway through the execution of the highest priority
    task, that task should:
            *  -  raise the priority of the middle-priority task with 10
            *  -  next immediately also raises the priority of the
    low-priority task with 10
            */
           if (num == 2 && runtime == EXECTIME/2)
           {
             printf("change prio task 0 to %d\n",LOW+10);
             ret=rt_task_set_priority(&demo_task[0],LOW+10);
             if ( ret != 0 ) printf("problem set on task 0 LOW+10 ret
    %d\n",ret);

             printf("change prio task 1 to %d\n",MID+10);
             ret=rt_task_set_priority(&demo_task[1],MID+10);

             if ( ret != 0 ) printf("problem set on task 1 MID+10  ret
    %d\n",ret);
           }
         }
         printf("End Task  : %d\n",num);
    }

    //startup code
    void startup()
    {
       int ret;
       RT_TASK_INFO taskinfo;
       int i;
       char  str[20] ;
       // semaphore to sync task startup on
       rt_sem_create(&mysync,"MySemaphore",0,S_FIFO);

       for(i=0; i < NTASKS; i++) {
         printf("start task  : %d\n",i);
         sprintf(str,"task%d",i);
         rt_task_create(&demo_task[i], str, 0, 50, 0);
         rt_task_start(&demo_task[i], &demo, &i);
       }
       for(i=0; i < NTASKS; i++) {
         ret=rt_task_inquire(&demo_task[i],&taskinfo);
         if ( ret != 0 ) printf("problem rt_task_inquire\n");
         printf("Task name and prio : %s  %d \n",
    taskinfo.name,taskinfo.prio);
       }
       // assign priorities to tasks

       ret=rt_task_set_priority(&demo_task[0],LOW);
       if ( ret != 0 ) printf("problem set LOW\n");
       ret=rt_task_set_priority(&demo_task[1],MID);
       if ( ret != 0 ) printf("problem set MID\n");
       ret=rt_task_set_priority(&demo_task[2],HIGH);
       if ( ret != 0 ) printf("problem set HIGH\n");

       for(i=0; i < NTASKS; i++) {
         ret=rt_task_inquire(&demo_task[i],&taskinfo);
         if ( ret != 0 ) printf("problem rt_task_inquire\n");
         printf("Task name and prio : %s  %d \n",
    taskinfo.name,taskinfo.prio);
       }

       printf("wake up all tasks\n");
       rt_sem_broadcast(&mysync);
    }

    int main(int argc, char* argv[])
    {
       startup();
       printf("\nType CTRL-C to end this program\n\n" );
       pause();
    }


gives the following output:

    start task  : 0
    Task  : 0
    start task  : 1
    Task  : 1
    start task  : 2
    Task  : 2
    Task name and prio : task0  50
    Task name and prio : task1  50
    Task name and prio : task2  50
    Task name and prio : task0  50
    Task name and prio : task1  51
    Task name and prio : task2  52
    wake up all tasks
    Running Task  : 2  prio: 52 at ms : 10
    Running Task  : 2  prio: 52 at ms : 20
    Running Task  : 2  prio: 52 at ms : 30
    Running Task  : 2  prio: 52 at ms : 40
    Running Task  : 2  prio: 52 at ms : 50
    Running Task  : 2  prio: 52 at ms : 60
    Running Task  : 2  prio: 52 at ms : 70
    Running Task  : 2  prio: 52 at ms : 80
    Running Task  : 2  prio: 52 at ms : 90
    Running Task  : 2  prio: 52 at ms : 100
    change prio task 0 to 60
    Running Task  : 1  prio: 51 at ms : 10
    Running Task  : 1  prio: 51 at ms : 20
    Running Task  : 1  prio: 51 at ms : 30
    Running Task  : 1  prio: 51 at ms : 40
    Running Task  : 1  prio: 51 at ms : 50
    Running Task  : 1  prio: 51 at ms : 60
    Running Task  : 1  prio: 51 at ms : 70
    Running Task  : 1  prio: 51 at ms : 80
    Running Task  : 1  prio: 51 at ms : 90
    Running Task  : 1  prio: 51 at ms : 100
    Running Task  : 1  prio: 51 at ms : 110
    Running Task  : 1  prio: 51 at ms : 120
    Running Task  : 1  prio: 51 at ms : 130
    Running Task  : 1  prio: 51 at ms : 140
    Running Task  : 1  prio: 51 at ms : 150
    Running Task  : 1  prio: 51 at ms : 160
    Running Task  : 1  prio: 51 at ms : 170
    Running Task  : 1  prio: 51 at ms : 180
    Running Task  : 1  prio: 51 at ms : 190
    Running Task  : 1  prio: 51 at ms : 200
    End Task  : 1
    Running Task  : 0  prio: 50 at ms : 10
    Running Task  : 0  prio: 50 at ms : 20
    Running Task  : 0  prio: 50 at ms : 30
    Running Task  : 0  prio: 50 at ms : 40
    Running Task  : 0  prio: 50 at ms : 50
    Running Task  : 0  prio: 50 at ms : 60
    Running Task  : 0  prio: 50 at ms : 70
    Running Task  : 0  prio: 50 at ms : 80
    Running Task  : 0  prio: 50 at ms : 90
    Running Task  : 0  prio: 50 at ms : 100
    Running Task  : 0  prio: 50 at ms : 110
    Running Task  : 0  prio: 50 at ms : 120
    Running Task  : 0  prio: 50 at ms : 130
    Running Task  : 0  prio: 50 at ms : 140
    Running Task  : 0  prio: 50 at ms : 150
    Running Task  : 0  prio: 50 at ms : 160
    Running Task  : 0  prio: 50 at ms : 170
    Running Task  : 0  prio: 50 at ms : 180
    Running Task  : 0  prio: 50 at ms : 190
    Running Task  : 0  prio: 50 at ms : 200
    End Task  : 0
    change prio task 1 to 61
    Running Task  : 2  prio: 52 at ms : 110
    Running Task  : 2  prio: 52 at ms : 120
    Running Task  : 2  prio: 52 at ms : 130
    Running Task  : 2  prio: 52 at ms : 140
    Running Task  : 2  prio: 52 at ms : 150
    Running Task  : 2  prio: 52 at ms : 160
    Running Task  : 2  prio: 52 at ms : 170
    Running Task  : 2  prio: 52 at ms : 180
    Running Task  : 2  prio: 52 at ms : 190
    Running Task  : 2  prio: 52 at ms : 200
    End Task  : 2

    Type CTRL-C to end this program

-------------- next part --------------
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <alchemy/task.h>
#include <alchemy/sem.h>
#include <alchemy/timer.h>

#define NTASKS 3
#define HIGH 52 /* high priority */
#define MID 51 /* medium priority */
#define LOW 50  /* low priority */

RT_TASK demo_task[NTASKS];
RT_SEM mysync;

#define EXECTIME   2e8   // execution time in ns
#define SPINTIME   1e7   // spin time in ns
#define SLEEPTIME   1e9   // sleep time in ns

void demo(void *arg)
{
    int ret;
    RT_TASK *curtask;
    RTIME starttime, runtime;
    RT_TASK_INFO taskinfo;
    int num=*(int *)arg;
    printf("Task  : %d\n",num);
    rt_sem_p(&mysync,TM_INFINITE);


    runtime = 0;
    while(runtime < EXECTIME) {
      rt_timer_spin(SPINTIME);  // spin cpu doing nothing
      runtime = runtime + SPINTIME;

      // inquire current task
      curtask=rt_task_self();
      rt_task_inquire(curtask,&taskinfo);

      printf("Running Task  : %d  prio: %d at ms : %d    \n",num,(int)taskinfo.prio,(int) runtime/1000000);

      /**
       * Halfway through the execution of the highest priority task, that task should:
       *  -  raise the priority of the middle-priority task with 10
       *  -  next immediately also raises the priority of the low-priority task with 10
       */
      if (num == 2 && runtime == EXECTIME/2)
      {
        printf("change prio task 0 to %d\n",LOW+10);
        ret=rt_task_set_priority(&demo_task[0],LOW+10);
        if ( ret != 0 ) printf("problem set on task 0 LOW+10 ret %d\n",ret);

        printf("change prio task 1 to %d\n",MID+10);
        ret=rt_task_set_priority(&demo_task[1],MID+10);

        if ( ret != 0 ) printf("problem set on task 1 MID+10  ret %d\n",ret);
      }
    }
    printf("End Task  : %d\n",num);
}

//startup code
void startup()
{
  int ret;
  RT_TASK_INFO taskinfo;
  int i;
  char  str[20] ;
  // semaphore to sync task startup on
  rt_sem_create(&mysync,"MySemaphore",0,S_FIFO);

  for(i=0; i < NTASKS; i++) {
    printf("start task  : %d\n",i);
    sprintf(str,"task%d",i);
    rt_task_create(&demo_task[i], str, 0, 50, 0);
    rt_task_start(&demo_task[i], &demo, &i);
  }
  for(i=0; i < NTASKS; i++) {
    ret=rt_task_inquire(&demo_task[i],&taskinfo);
    if ( ret != 0 ) printf("problem rt_task_inquire\n");
    printf("Task name and prio : %s  %d \n", taskinfo.name,taskinfo.prio);
  }
  // assign priorities to tasks

  ret=rt_task_set_priority(&demo_task[0],LOW);
  if ( ret != 0 ) printf("problem set LOW\n");
  ret=rt_task_set_priority(&demo_task[1],MID);
  if ( ret != 0 ) printf("problem set MID\n");
  ret=rt_task_set_priority(&demo_task[2],HIGH);
  if ( ret != 0 ) printf("problem set HIGH\n");

  for(i=0; i < NTASKS; i++) {
    ret=rt_task_inquire(&demo_task[i],&taskinfo);
    if ( ret != 0 ) printf("problem rt_task_inquire\n");
    printf("Task name and prio : %s  %d \n", taskinfo.name,taskinfo.prio);
  }

  printf("wake up all tasks\n");
  rt_sem_broadcast(&mysync);
}

int main(int argc, char* argv[])
{
  startup();
  printf("\nType CTRL-C to end this program\n\n" );
  pause();
}

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
  2020-09-16 18:12 rt_task_set_priority does not increase priority of other task Harco Kuppens
@ 2020-09-17 11:51 ` Jan Kiszka
       [not found] ` <916ef19a754d4e42b0eaefa8a1a26060@EXPRD08.hosting.ru.nl>
  1 sibling, 0 replies; 9+ messages in thread
From: Jan Kiszka @ 2020-09-17 11:51 UTC (permalink / raw)
  To: Harco Kuppens, Xenomai@xenomai.org

On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
> 
> Hi,
> 
> I found a problem with rt_task_set_priority function which does not 
> increase priority of another task.
> However it works fine if you increase the priority of another task.
> 
> Below is an en example program and its output, and we run this program 
> on xenomai 3.08.
> The problem appears if we run the program on our xenomai image for the 
> raspberry pi 3,
> and is also appears in our virtual box image.
> Both images can be found at :
> 
>   * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>   * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
> 
> The easiest way is to run the virtualbox image.
> 
> The final question I have: is there an wrong usage of xenomai API in the 
> example program,
> or is this a bug in xenomai?
> 

Something is inconsistent here. Did you also check via 
/proc/xenomai/sched/threads if that view is consistent with the result 
of inquire? I vaguely recall issues of the latter but I also do not 
recall any fix to 3.1, not to speak of anything that was not backported.

BTW, tried 3.1 as well?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
       [not found] ` <916ef19a754d4e42b0eaefa8a1a26060@EXPRD08.hosting.ru.nl>
@ 2020-09-17 12:01   ` Harco Kuppens
  2020-09-17 13:26     ` Philippe Gerum
                       ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Harco Kuppens @ 2020-09-17 12:01 UTC (permalink / raw)
  To: Jan Kiszka, Xenomai@xenomai.org



On 17/09/2020 13:51, Jan Kiszka wrote:
> On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
>> Hi,
>>
>> I found a problem with rt_task_set_priority function which does not
>> increase priority of another task.
>> However it works fine if you increase the priority of another task.
>>
>> Below is an en example program and its output, and we run this program
>> on xenomai 3.08.
>> The problem appears if we run the program on our xenomai image for the
>> raspberry pi 3,
>> and is also appears in our virtual box image.
>> Both images can be found at :
>>
>>    * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>>    * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
>>
>> The easiest way is to run the virtualbox image.
>>
>> The final question I have: is there an wrong usage of xenomai API in the
>> example program,
>> or is this a bug in xenomai?
>>
> Something is inconsistent here. Did you also check via
> /proc/xenomai/sched/threads if that view is consistent with the result
> of inquire?
yes, and they also said the priority was not increased.
You can repeat the experiment in the virtualbox image.
Note: we use virtualbox so that students can do some exercise at home. 
The exerecises on hardware they must do on raspberry pi 3 in the lab.
Normally a rt os on virtualbox would make no sense.
> I vaguely recall issues of the latter but I also do not
> recall any fix to 3.1, not to speak of anything that was not backported.

> BTW, tried 3.1 as well?
no, because I don't have it  installed. Could someone who has it running 
try this example on it, and check whether this   problem also occurs there?

Anyway it was pretty difficult to get xenomai 3.08 with gpio support to 
work on the raspberry pi 3.
Took me a long time, and I rather stick with 3.0.8.
We use raspberry pi's in a course on the radboud university where 
students get exercises in learning to use xenomai.
Switching to new version would mean lot of work for me.

Harco
>
> Jan
>



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
  2020-09-17 12:01   ` Harco Kuppens
@ 2020-09-17 13:26     ` Philippe Gerum
  2020-09-17 13:31     ` Jan Kiszka
       [not found]     ` <6318b8f4918243c891732fc8f79d11ab@EXPRD08.hosting.ru.nl>
  2 siblings, 0 replies; 9+ messages in thread
From: Philippe Gerum @ 2020-09-17 13:26 UTC (permalink / raw)
  To: Harco Kuppens; +Cc: Jan Kiszka, xenomai


Harco Kuppens via Xenomai <xenomai@xenomai.org> writes:

> On 17/09/2020 13:51, Jan Kiszka wrote:
>> On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
>>> Hi,
>>>
>>> I found a problem with rt_task_set_priority function which does not
>>> increase priority of another task.
>>> However it works fine if you increase the priority of another task.
>>>
>>> Below is an en example program and its output, and we run this program
>>> on xenomai 3.08.
>>> The problem appears if we run the program on our xenomai image for the
>>> raspberry pi 3,
>>> and is also appears in our virtual box image.
>>> Both images can be found at :
>>>
>>>    * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>>>    * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
>>>
>>> The easiest way is to run the virtualbox image.
>>>
>>> The final question I have: is there an wrong usage of xenomai API in the
>>> example program,
>>> or is this a bug in xenomai?
>>>
>> Something is inconsistent here. Did you also check via
>> /proc/xenomai/sched/threads if that view is consistent with the result
>> of inquire?
> yes, and they also said the priority was not increased.
> You can repeat the experiment in the virtualbox image.
> Note: we use virtualbox so that students can do some exercise at
> home. The exerecises on hardware they must do on raspberry pi 3 in the
> lab.
> Normally a rt os on virtualbox would make no sense.
>> I vaguely recall issues of the latter but I also do not
>> recall any fix to 3.1, not to speak of anything that was not backported.
>
>> BTW, tried 3.1 as well?
> no, because I don't have it  installed. Could someone who has it
> running try this example on it, and check whether this   problem also
> occurs there?
>
> Anyway it was pretty difficult to get xenomai 3.08 with gpio support
> to work on the raspberry pi 3.
> Took me a long time, and I rather stick with 3.0.8.
> We use raspberry pi's in a course on the radboud university where
> students get exercises in learning to use xenomai.
> Switching to new version would mean lot of work for me.
>

Ok, I'll have a look asap in the coming days and follow up on this.

-- 
Philippe.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
  2020-09-17 12:01   ` Harco Kuppens
  2020-09-17 13:26     ` Philippe Gerum
@ 2020-09-17 13:31     ` Jan Kiszka
  2020-09-17 17:49       ` Philippe Gerum
       [not found]       ` <0efdb308f2414013882d20061d07a2d7@EXPRD08.hosting.ru.nl>
       [not found]     ` <6318b8f4918243c891732fc8f79d11ab@EXPRD08.hosting.ru.nl>
  2 siblings, 2 replies; 9+ messages in thread
From: Jan Kiszka @ 2020-09-17 13:31 UTC (permalink / raw)
  To: Harco Kuppens, Xenomai@xenomai.org, Greg Gallagher, Philippe Gerum

On 17.09.20 14:01, Harco Kuppens wrote:
> 
> 
> On 17/09/2020 13:51, Jan Kiszka wrote:
>> On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
>>> Hi,
>>>
>>> I found a problem with rt_task_set_priority function which does not
>>> increase priority of another task.
>>> However it works fine if you increase the priority of another task.
>>>
>>> Below is an en example program and its output, and we run this program
>>> on xenomai 3.08.
>>> The problem appears if we run the program on our xenomai image for the
>>> raspberry pi 3,
>>> and is also appears in our virtual box image.
>>> Both images can be found at :
>>>
>>>    * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>>>    * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
>>>
>>> The easiest way is to run the virtualbox image.
>>>
>>> The final question I have: is there an wrong usage of xenomai API in the
>>> example program,
>>> or is this a bug in xenomai?
>>>
>> Something is inconsistent here. Did you also check via
>> /proc/xenomai/sched/threads if that view is consistent with the result
>> of inquire?
> yes, and they also said the priority was not increased.
> You can repeat the experiment in the virtualbox image.
> Note: we use virtualbox so that students can do some exercise at home. 
> The exerecises on hardware they must do on raspberry pi 3 in the lab.
> Normally a rt os on virtualbox would make no sense.

I'm doing most of Xenomai development in KVM, including kernel debugging 
- no need to explain ;).

>> I vaguely recall issues of the latter but I also do not
>> recall any fix to 3.1, not to speak of anything that was not backported.
> 
>> BTW, tried 3.1 as well?
> no, because I don't have it  installed. Could someone who has it running 
> try this example on it, and check whether this   problem also occurs there?
> 

There is something unexpected with master and also with 
--enable-lazy-setsched. It's important to note that without that 
feature, include for 3.0 which lacked that, the setprio call will switch 
the caller into secondary mode. Still, that alone does not explain the 
result to me yet. Thanks in advanced to Philippe to picking this up!

> Anyway it was pretty difficult to get xenomai 3.08 with gpio support to 
> work on the raspberry pi 3.

Not sure ATM where we stand with that platform and the GPIO enabling. 
Greg, Philippe?

> Took me a long time, and I rather stick with 3.0.8.
> We use raspberry pi's in a course on the radboud university where 
> students get exercises in learning to use xenomai.
> Switching to new version would mean lot of work for me.
> 

We maintain the demo image generator 
https://gitlab.denx.de/Xenomai/xenomai-images. There is no raspi target 
yet, but it would likely make sense to add one eventually so that you 
can easily generate SD card images, or even add own customizations on 
top. I'm happy to explain more if there is interest.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
       [not found]     ` <6318b8f4918243c891732fc8f79d11ab@EXPRD08.hosting.ru.nl>
@ 2020-09-17 13:59       ` Harco Kuppens
  0 siblings, 0 replies; 9+ messages in thread
From: Harco Kuppens @ 2020-09-17 13:59 UTC (permalink / raw)
  To: Jan Kiszka, Xenomai@xenomai.org, Greg Gallagher, Philippe Gerum



On 17/09/2020 15:31, Jan Kiszka wrote:
>
> We maintain the demo image generator
> https://gitlab.denx.de/Xenomai/xenomai-images. There is no raspi target
> yet, but it would likely make sense to add one eventually so that you
> can easily generate SD card images, or even add own customizations on
> top. I'm happy to explain more if there is interest.
Adding a raspi target would be great!

The problem with the raspberry pi is that they don't use the vanilla 
kernel source,
but have their own patched kernel in a git repo. Then you have to apply 
the ipipe patch, and
a patch to get gpio to work. After some hacking I got it working,
but there was still a problem with interrupts in the pipeline not 
getting through to linux.
I reported that at the mailinglist:
   https://www.xenomai.org/pipermail/xenomai/2019-June/041023.html
but it never got resolved. But anyway, xenomai was working with xenomai,
so we could use it in the course. The only thing is that because the 
interrupts are not reaching
linux you still have less confidence in the image.
My installation instructions are also linked at 
http://www.cs.ru.nl/lab/xenomai/virtualbox.html

There is even a raspberrypi 4, but I couldn't that get to work with 
xenomai3 with gpio support.
Others seem to have more succes later: 
http://www.simplerobot.net/2019/12/xenomai-3-for-raspberry-pi-4.html
They also needed to do extra patching.

However it would be great if the raspberry pi would be officially 
supported, because
it is a very well known platform nowadays. Ideal for practica in teaching.

Finally it must be noted that the virtualbox image is just for intel 
architecture and
that was easy to setup without any hacking. There the problem with 
raising the priority
also happens, so the problem is unrelated to any problems with my rpi image.

Harco
>
> Jan
>



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
  2020-09-17 13:31     ` Jan Kiszka
@ 2020-09-17 17:49       ` Philippe Gerum
       [not found]       ` <0efdb308f2414013882d20061d07a2d7@EXPRD08.hosting.ru.nl>
  1 sibling, 0 replies; 9+ messages in thread
From: Philippe Gerum @ 2020-09-17 17:49 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Harco Kuppens, Xenomai@xenomai.org, Greg Gallagher


Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 17.09.20 14:01, Harco Kuppens wrote:
>> 
>> On 17/09/2020 13:51, Jan Kiszka wrote:
>>> On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
>>>> Hi,
>>>>
>>>> I found a problem with rt_task_set_priority function which does not
>>>> increase priority of another task.
>>>> However it works fine if you increase the priority of another task.
>>>>
>>>> Below is an en example program and its output, and we run this program
>>>> on xenomai 3.08.
>>>> The problem appears if we run the program on our xenomai image for the
>>>> raspberry pi 3,
>>>> and is also appears in our virtual box image.
>>>> Both images can be found at :
>>>>
>>>>    * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>>>>    * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
>>>>
>>>> The easiest way is to run the virtualbox image.
>>>>
>>>> The final question I have: is there an wrong usage of xenomai API in the
>>>> example program,
>>>> or is this a bug in xenomai?
>>>>
>>> Something is inconsistent here. Did you also check via
>>> /proc/xenomai/sched/threads if that view is consistent with the result
>>> of inquire?
>> yes, and they also said the priority was not increased.
>> You can repeat the experiment in the virtualbox image.
>> Note: we use virtualbox so that students can do some exercise at
>> home. The exerecises on hardware they must do on raspberry pi 3 in
>> the lab.
>> Normally a rt os on virtualbox would make no sense.
>
> I'm doing most of Xenomai development in KVM, including kernel
> debugging - no need to explain ;).
>
>>> I vaguely recall issues of the latter but I also do not
>>> recall any fix to 3.1, not to speak of anything that was not backported.
>> 
>>> BTW, tried 3.1 as well?
>> no, because I don't have it  installed. Could someone who has it
>> running try this example on it, and check whether this   problem
>> also occurs there?
>> 
>
> There is something unexpected with master and also with
> --enable-lazy-setsched. It's important to note that without that 
> feature, include for 3.0 which lacked that, the setprio call will
> switch the caller into secondary mode. Still, that alone does not
> explain the result to me yet. Thanks in advanced to Philippe to
> picking this up!

Tricky.

In absence of --enable-lazy-setsched, we know that t2 switches to
secondary mode as a result of calling rt_task_set_priority(), for the
purpose of eagerly propagating the priority update first to the main
(kernel) scheduler, _before_ telling Cobalt about it.

t1 then t0 - which are still controlled by the Cobalt scheduler - may
preempt t2, which runs code somewhere between
__STD(pthread_setschedparam()) and
XENOMAI_SYSCALL(sc_cobalt_thread_setschedparam_ex) in
pthread_setschedparam_ex(), as they wake up from rt_timer_spin().

The printf() output may be confusing, because as we see the "change prio
task X to Y" message, we still cannot assume the operation was completed
just yet. As mentioned earlier, t2 is crawling on the root stage at this
point (low priority stage of the pipeline).

As t1 then t0 grab the CPU which t2 just yielded, they manage to run
their respective loop entirely before t2 has a chance to leave the
(low-priority) secondary mode, displaying the old priority value
Cobalt-wise, which is still pending update.

In short, building with --enable-lazy-setsched may mitigate the issue in
most cases, but there is no way to strictly synchronize the main and
Cobalt schedulers when it comes to updating thread priorities only using
the plain rt_task_set_priority()/pthread_setschedparam_ex() calls. There
will always be a delay between the two updates, you only get to chose
whether you want the main (linux) scheduler to be updated first at the
expense of a mode switch, or Cobalt should be told first about the
change (sparing a transition to secondary mode in the process), and the
main kernel would be notified next.

In the latter case, there is another gotcha involving glibc's caching of
a pthread priority value: with --enable-lazy-setsched, that cached value
won't be updated with the new value passed to rt_task_set_priority(), so
__STD(pthread_getschedparam()) may return the old priority. Some
comments in pthread_getschedparam_ex() give details.

>
>> Anyway it was pretty difficult to get xenomai 3.08 with gpio support
>> to work on the raspberry pi 3.
>
> Not sure ATM where we stand with that platform and the GPIO
> enabling. Greg, Philippe?

The common bcm2835-gpio chip is supported by the real-time GPIO
framework. The RPI-specific GPIO expander is not though.

-- 
Philippe.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
       [not found]       ` <0efdb308f2414013882d20061d07a2d7@EXPRD08.hosting.ru.nl>
@ 2020-09-23 12:58         ` Harco Kuppens
  2020-09-27  9:24           ` Philippe Gerum
  0 siblings, 1 reply; 9+ messages in thread
From: Harco Kuppens @ 2020-09-23 12:58 UTC (permalink / raw)
  To: Philippe Gerum, Jan Kiszka
  Cc: Xenomai@xenomai.org, Greg Gallagher, Hooman, J.J.M. (Jozef)



On 17/09/2020 19:49, Philippe Gerum wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> On 17.09.20 14:01, Harco Kuppens wrote:
>>> On 17/09/2020 13:51, Jan Kiszka wrote:
>>>> On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
>>>>> Hi,
>>>>>
>>>>> I found a problem with rt_task_set_priority function which does not
>>>>> increase priority of another task.
>>>>> However it works fine if you increase the priority of another task.
>>>>>
>>>>> Below is an en example program and its output, and we run this program
>>>>> on xenomai 3.08.
>>>>> The problem appears if we run the program on our xenomai image for the
>>>>> raspberry pi 3,
>>>>> and is also appears in our virtual box image.
>>>>> Both images can be found at :
>>>>>
>>>>>     * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>>>>>     * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
>>>>>
>>>>> The easiest way is to run the virtualbox image.
>>>>>
>>>>> The final question I have: is there an wrong usage of xenomai API in the
>>>>> example program,
>>>>> or is this a bug in xenomai?
>>>>>
>>>> Something is inconsistent here. Did you also check via
>>>> /proc/xenomai/sched/threads if that view is consistent with the result
>>>> of inquire?
>>> yes, and they also said the priority was not increased.
>>> You can repeat the experiment in the virtualbox image.
>>> Note: we use virtualbox so that students can do some exercise at
>>> home. The exerecises on hardware they must do on raspberry pi 3 in
>>> the lab.
>>> Normally a rt os on virtualbox would make no sense.
>> I'm doing most of Xenomai development in KVM, including kernel
>> debugging - no need to explain ;).
>>
>>>> I vaguely recall issues of the latter but I also do not
>>>> recall any fix to 3.1, not to speak of anything that was not backported.
>>>> BTW, tried 3.1 as well?
>>> no, because I don't have it  installed. Could someone who has it
>>> running try this example on it, and check whether this   problem
>>> also occurs there?
>>>
>> There is something unexpected with master and also with
>> --enable-lazy-setsched. It's important to note that without that
>> feature, include for 3.0 which lacked that, the setprio call will
>> switch the caller into secondary mode. Still, that alone does not
>> explain the result to me yet. Thanks in advanced to Philippe to
>> picking this up!
> Tricky.
>
> In absence of --enable-lazy-setsched, we know that t2 switches to
> secondary mode as a result of calling rt_task_set_priority(), for the
> purpose of eagerly propagating the priority update first to the main
> (kernel) scheduler, _before_ telling Cobalt about it.
>
> t1 then t0 - which are still controlled by the Cobalt scheduler - may
> preempt t2, which runs code somewhere between
> __STD(pthread_setschedparam()) and
> XENOMAI_SYSCALL(sc_cobalt_thread_setschedparam_ex) in
> pthread_setschedparam_ex(), as they wake up from rt_timer_spin().
>
> The printf() output may be confusing, because as we see the "change prio
> task X to Y" message, we still cannot assume the operation was completed
> just yet. As mentioned earlier, t2 is crawling on the root stage at this
> point (low priority stage of the pipeline).
>
> As t1 then t0 grab the CPU which t2 just yielded, they manage to run
> their respective loop entirely before t2 has a chance to leave the
> (low-priority) secondary mode, displaying the old priority value
> Cobalt-wise, which is still pending update.
>
> In short, building with --enable-lazy-setsched may mitigate the issue in
> most cases, but there is no way to strictly synchronize the main and
> Cobalt schedulers when it comes to updating thread priorities only using
> the plain rt_task_set_priority()/pthread_setschedparam_ex() calls. There
> will always be a delay between the two updates, you only get to chose
> whether you want the main (linux) scheduler to be updated first at the
> expense of a mode switch, or Cobalt should be told first about the
> change (sparing a transition to secondary mode in the process), and the
> main kernel would be notified next.
>
> In the latter case, there is another gotcha involving glibc's caching of
> a pthread priority value: with --enable-lazy-setsched, that cached value
> won't be updated with the new value passed to rt_task_set_priority(), so
> __STD(pthread_getschedparam()) may return the old priority. Some
> comments in pthread_getschedparam_ex() give details.

I found a mistake in original problem statement

   I found a problem with rt_task_set_priority function which does not
   increase priority of another task.
   However it works fine if you increase the priority of another task.

The second line should have been:

  However it works fine if you increase the priority of the current task from the task itself.

I didn't completely understand the responses I got,
but can I conclude that  setting the priority of another task with the
rt_task_set_priority function just doesn't work?
Should that be fixed? Or must that be pointed out in the documentation?

Best regards,
Harco Kuppens






^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: rt_task_set_priority does not increase priority of other task
  2020-09-23 12:58         ` Harco Kuppens
@ 2020-09-27  9:24           ` Philippe Gerum
  0 siblings, 0 replies; 9+ messages in thread
From: Philippe Gerum @ 2020-09-27  9:24 UTC (permalink / raw)
  To: Harco Kuppens
  Cc: Jan Kiszka, Xenomai@xenomai.org, Greg Gallagher, Hooman, J.J.M. (Jozef)


Harco Kuppens <h.kuppens@cs.ru.nl> writes:

> On 17/09/2020 19:49, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> On 17.09.20 14:01, Harco Kuppens wrote:
>>>> On 17/09/2020 13:51, Jan Kiszka wrote:
>>>>> On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I found a problem with rt_task_set_priority function which does not
>>>>>> increase priority of another task.
>>>>>> However it works fine if you increase the priority of another task.
>>>>>>
>>>>>> Below is an en example program and its output, and we run this program
>>>>>> on xenomai 3.08.
>>>>>> The problem appears if we run the program on our xenomai image for the
>>>>>> raspberry pi 3,
>>>>>> and is also appears in our virtual box image.
>>>>>> Both images can be found at :
>>>>>>
>>>>>>     * http://www.cs.ru.nl/lab/xenomai/raspberrypi.html
>>>>>>     * http://www.cs.ru.nl/lab/xenomai/virtualbox.html
>>>>>>
>>>>>> The easiest way is to run the virtualbox image.
>>>>>>
>>>>>> The final question I have: is there an wrong usage of xenomai API in the
>>>>>> example program,
>>>>>> or is this a bug in xenomai?
>>>>>>
>>>>> Something is inconsistent here. Did you also check via
>>>>> /proc/xenomai/sched/threads if that view is consistent with the result
>>>>> of inquire?
>>>> yes, and they also said the priority was not increased.
>>>> You can repeat the experiment in the virtualbox image.
>>>> Note: we use virtualbox so that students can do some exercise at
>>>> home. The exerecises on hardware they must do on raspberry pi 3 in
>>>> the lab.
>>>> Normally a rt os on virtualbox would make no sense.
>>> I'm doing most of Xenomai development in KVM, including kernel
>>> debugging - no need to explain ;).
>>>
>>>>> I vaguely recall issues of the latter but I also do not
>>>>> recall any fix to 3.1, not to speak of anything that was not backported.
>>>>> BTW, tried 3.1 as well?
>>>> no, because I don't have it  installed. Could someone who has it
>>>> running try this example on it, and check whether this   problem
>>>> also occurs there?
>>>>
>>> There is something unexpected with master and also with
>>> --enable-lazy-setsched. It's important to note that without that
>>> feature, include for 3.0 which lacked that, the setprio call will
>>> switch the caller into secondary mode. Still, that alone does not
>>> explain the result to me yet. Thanks in advanced to Philippe to
>>> picking this up!
>> Tricky.
>>
>> In absence of --enable-lazy-setsched, we know that t2 switches to
>> secondary mode as a result of calling rt_task_set_priority(), for the
>> purpose of eagerly propagating the priority update first to the main
>> (kernel) scheduler, _before_ telling Cobalt about it.
>>
>> t1 then t0 - which are still controlled by the Cobalt scheduler - may
>> preempt t2, which runs code somewhere between
>> __STD(pthread_setschedparam()) and
>> XENOMAI_SYSCALL(sc_cobalt_thread_setschedparam_ex) in
>> pthread_setschedparam_ex(), as they wake up from rt_timer_spin().
>>
>> The printf() output may be confusing, because as we see the "change prio
>> task X to Y" message, we still cannot assume the operation was completed
>> just yet. As mentioned earlier, t2 is crawling on the root stage at this
>> point (low priority stage of the pipeline).
>>
>> As t1 then t0 grab the CPU which t2 just yielded, they manage to run
>> their respective loop entirely before t2 has a chance to leave the
>> (low-priority) secondary mode, displaying the old priority value
>> Cobalt-wise, which is still pending update.
>>
>> In short, building with --enable-lazy-setsched may mitigate the issue in
>> most cases, but there is no way to strictly synchronize the main and
>> Cobalt schedulers when it comes to updating thread priorities only using
>> the plain rt_task_set_priority()/pthread_setschedparam_ex() calls. There
>> will always be a delay between the two updates, you only get to chose
>> whether you want the main (linux) scheduler to be updated first at the
>> expense of a mode switch, or Cobalt should be told first about the
>> change (sparing a transition to secondary mode in the process), and the
>> main kernel would be notified next.
>>
>> In the latter case, there is another gotcha involving glibc's caching of
>> a pthread priority value: with --enable-lazy-setsched, that cached value
>> won't be updated with the new value passed to rt_task_set_priority(), so
>> __STD(pthread_getschedparam()) may return the old priority. Some
>> comments in pthread_getschedparam_ex() give details.
>
> I found a mistake in original problem statement
>
>   I found a problem with rt_task_set_priority function which does not
>   increase priority of another task.
>   However it works fine if you increase the priority of another task.
>
> The second line should have been:
>
>  However it works fine if you increase the priority of the current task from the task itself.
>
> I didn't completely understand the responses I got,
> but can I conclude that  setting the priority of another task with the
> rt_task_set_priority function just doesn't work?

This is not a bug per se but a limitation which is inherent to the dual
kernel design: there are two schedulers which should receive the
priority change request, and there is no way to apply such change
atomically to both kernels while keeping them running asynchronously, so
that the real-time core is not affected by the main kernel latency.

By default, libcobalt assumes that it is ok to temporarily switch a
thread issuing such a request to secondary mode, in order to first tell
the main kernel about the change, then tell Cobalt eventually. The
behavior you observed is directly related to that switch, which causes
the caller priority to drop below any real-time priority for a while
(i.e. until the request is sent to Cobalt, which causes a converse
switch to primary mode).

At build time, you may pass --enable-lazy-setsched to the configure
script to override the default setting, telling libcobalt to defer
priority change requests to the main kernel until after the calling
thread issues a regular (non-Cobalt) system call, at some point in the
future. The net effect doing so is that the Cobalt scheduler would
receive the priority change first, and no demotion to secondary mode
would happen as a result of calling rt_task_set_priority(), therefore
the test program should behave the expected way.

> Should that be fixed? Or must that be pointed out in the documentation?
>

I believe you just pointed out a valuable contribution from anyone who
would care helping the project they benefit from. Updates to the
documentation can be sent to the list.

Thanks,

-- 
Philippe.


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-09-27  9:24 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-16 18:12 rt_task_set_priority does not increase priority of other task Harco Kuppens
2020-09-17 11:51 ` Jan Kiszka
     [not found] ` <916ef19a754d4e42b0eaefa8a1a26060@EXPRD08.hosting.ru.nl>
2020-09-17 12:01   ` Harco Kuppens
2020-09-17 13:26     ` Philippe Gerum
2020-09-17 13:31     ` Jan Kiszka
2020-09-17 17:49       ` Philippe Gerum
     [not found]       ` <0efdb308f2414013882d20061d07a2d7@EXPRD08.hosting.ru.nl>
2020-09-23 12:58         ` Harco Kuppens
2020-09-27  9:24           ` Philippe Gerum
     [not found]     ` <6318b8f4918243c891732fc8f79d11ab@EXPRD08.hosting.ru.nl>
2020-09-17 13:59       ` Harco Kuppens

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.