[Xenomai] questions regarding context switch

[Xenomai] questions regarding context switch

[Tom Z]

Hi,

I have a user-space program that spawns 8 periodic RT_TASKs for 
execution. Each RT_TASK's code is very simple: it just loops for 10 
periods during each of which rt_timer_spin is called to consume some 
CPU. The periods of these RT_TASKs vary from 150 ms to 1 s, and during 
each of their periods, the RT_TASKs consume CPU for from 20 ms to 100 
ms, At the end of the program, I read rt_task_info::ctxswitches 
<http://www.xenomai.org/documentation/xenomai-2.6/html/api/structrt__task__info.html#a8d72c536900a743d462c8566ec28cab8> 
of one RT_TASK, and got 12, which means, if I understand it correctly, 
this task has 12 context switches during the program's execution. (The 
number of context switches of an RT_TASK should vary during each run of 
the program, but since my program is running only for a very short time, 
and only 8 RT_TASKs are running, this number should not vary much each 
time, and actually I got 12 each time I ran my program )

Now in addition to the execution of the above 8 RT_TASKs, I did an extra 
thing: I create a kernel module that setup a periodic RT_ALARM with a 
period of 250 us. This RT_ALARM starts immediately after the kernel 
module is loaded.The handler of this RT_ALARM simply increases a global 
counter by 1, so it gives the number of ALARM shots (expires).  Then I 
run the above user-space program again with the RT_ALARM being active, 
and after it finishes, I find that while the RT_ALARM has thousands of 
shots, the number of context switches ( rt_task_info::ctxswitches 
<http://www.xenomai.org/documentation/xenomai-2.6/html/api/structrt__task__info.html#a8d72c536900a743d462c8566ec28cab8>) 
of the task mentioned above is still 12. Here is what I don't 
understand: when an RT_ALARM expires and executes a handler, shouldn't 
there be a context switch if an RT_TASK is running? The task mentioned 
above executes rt_timer_spin for 100ms during each period, and the 
highest priority among all the 8 tasks, so while it is executing, the 
RT_ALARM must expire for many times -- but why does it NOT increase the 
number of the tasks' context switches?

Thanks,
Tom

Re: [Xenomai] questions regarding context switch

[Gilles Chanteperdrix]

On 03/21/2013 10:02 PM, Tom Z wrote:

> when an RT_ALARM expires and executes a handler, shouldn't 
> there be a context switch if an RT_TASK is running? The task mentioned 
> above executes rt_timer_spin for 100ms during each period, and the 
> highest priority among all the 8 tasks, so while it is executing, the 
> RT_ALARM must expire for many times -- but why does it NOT increase the 
> number of the tasks' context switches?


Hi,

Because the number of context switches is the number of task switches.
An alarm in kernel-space is simply triggered on the timer interrupt, so,
it does not need any task switch. An alarm is not a task.

Any news about the issue you described here:
http://www.xenomai.org/pipermail/xenomai/2013-March/028005.html
?

Regards.


-- 
                                                                Gilles.

Re: [Xenomai] questions regarding context switch

[Tom Z]

Hi Gilles,

Thanks for your prompt reply. You are amazing:)

> Any news about the issue you described here:
> http://www.xenomai.org/pipermail/xenomai/2013-March/028005.html
> ?
You are correct. The link order is wrong. I figured out a working order 
by trial&error, as follows:
CFLAGS=$(shell xeno-config --skin=native --cflags)
LDFLAGS=$(shell xeno-config --skin=native --ldflags)
gcc $(CFLAGS) main.c $(LDFLAGS) -o main

Sincerely,
Tom

On 3/21/2013 4:07 PM, Gilles Chanteperdrix wrote:
> On 03/21/2013 10:02 PM, Tom Z wrote:
>
>> when an RT_ALARM expires and executes a handler, shouldn't
>> there be a context switch if an RT_TASK is running? The task mentioned
>> above executes rt_timer_spin for 100ms during each period, and the
>> highest priority among all the 8 tasks, so while it is executing, the
>> RT_ALARM must expire for many times -- but why does it NOT increase the
>> number of the tasks' context switches?
>
> Hi,
>
> Because the number of context switches is the number of task switches.
> An alarm in kernel-space is simply triggered on the timer interrupt, so,
> it does not need any task switch. An alarm is not a task.
>
> Any news about the issue you described here:
> http://www.xenomai.org/pipermail/xenomai/2013-March/028005.html
> ?
>
> Regards.
>
>