[Xenomai] [QUESTION] thread creation and hook function

[Xenomai] [QUESTION] thread creation and hook function

[alex alex]

Hi all,

I made a simple debugging program with the hook native functions and I
see something
I do not understand...

This program create 1 thread who loads the CPU for some time.

case 1 - Looking at the kernel log, we can see that the task is created in the
primary mode then immediatly switch to the secondary (it's the root linux
task who loads the cpu).

I made 2 others tests:
case 2 - When I release the context with a rt sleep function, we see that the
task remains in the primary mode during the CPU load.

case 3 - I try to use "pthread_set_mode_np(0, PTHREAD_PRIMARY)" to force
the task to remain in primary mode but I see that it's still the root task
who loads the cpu.

I would appreciate if someone could clear my head about this behavior.

Alex.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_switch.tar.bz2
Type: application/x-bzip2
Size: 2613 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130413/51834ca0/attachment.bin>

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/13/2013 06:58 PM, alex alex wrote:

> Hi all,
> 
> I made a simple debugging program with the hook native functions and I
> see something
> I do not understand...
> 
> This program create 1 thread who loads the CPU for some time.
> 
> case 1 - Looking at the kernel log, we can see that the task is created in the
> primary mode then immediatly switch to the secondary (it's the root linux
> task who loads the cpu).
> 
> I made 2 others tests:
> case 2 - When I release the context with a rt sleep function, we see that the
> task remains in the primary mode during the CPU load.
> 
> case 3 - I try to use "pthread_set_mode_np(0, PTHREAD_PRIMARY)" to force
> the task to remain in primary mode but I see that it's still the root task
> who loads the cpu.
> 
> I would appreciate if someone could clear my head about this behavior.


Well, to explain the behaviour, we would have to understand the
behaviour. Could you add comment in the code to explain what you do not
understand?

-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[alex alex]

I hope this is more clear like this.


2013/4/13 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> On 04/13/2013 06:58 PM, alex alex wrote:
>
> > Hi all,
> >
> > I made a simple debugging program with the hook native functions and I
> > see something
> > I do not understand...
> >
> > This program create 1 thread who loads the CPU for some time.
> >
> > case 1 - Looking at the kernel log, we can see that the task is created
> in the
> > primary mode then immediatly switch to the secondary (it's the root linux
> > task who loads the cpu).
> >
> > I made 2 others tests:
> > case 2 - When I release the context with a rt sleep function, we see
> that the
> > task remains in the primary mode during the CPU load.
> >
> > case 3 - I try to use "pthread_set_mode_np(0, PTHREAD_PRIMARY)" to force
> > the task to remain in primary mode but I see that it's still the root
> task
> > who loads the cpu.
> >
> > I would appreciate if someone could clear my head about this behavior.
>
>
> Well, to explain the behaviour, we would have to understand the
> behaviour. Could you add comment in the code to explain what you do not
> understand?
>
> --
>                                                                 Gilles.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_switch.tar.bz2
Type: application/x-bzip2
Size: 3255 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130413/e11e690c/attachment.bin>

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/13/2013 08:20 PM, alex alex wrote:

> I hope this is more clear like this.


We definitely do not have information. As usual, we do not know what
version of Xenomai you are using, on what platform, how your kernel is
configured.

/*
 * When case 1 is activated we see (with the dmesg command) :
 *
[  796.318290] HOOK: 107212ns - NAME "ROOT/0"
[  796.321501] HOOK: 3322158ns - NAME "hook"        <- task creation
(primary mode)
[  796.321512] HOOK: 3335024ns - NAME "ROOT/0"      <- immediate switch
in secondary mode and do cpu load (why this switch?)

1- a switch from "hook" to "ROOT" thread does not necessarily mean a
switch to secondary mode. It also happens if "hook" suspends, of if ROOT
preempts hook.
2- a switch to "hook" does not necessarily mean that the task startup is
done, if you have a look at the thread startup code, you will see that
has several steps, switching back and forth between the creator task and
the created task.
3- if it is indeed a switch to secondary mode, you can have a look at
examples/sigdebug.c to see how to find the reason for a secondary mode
switch.


[  796.526870] HOOK: 208957565ns - NAME "ROOT/0"
[  796.526927] HOOK: 209017235ns - NAME "ROOT/0"
[  797.525640] HOOK: 1209016502ns - NAME "hook"     <- the task is deleted
[  797.525642] HOOK: 1209020993ns - NAME "ROOT/0"
 *
 * case 2 : with the sleep function
 *
 1093.722850] HOOK: 109993ns - NAME "ROOT/0"
[ 1093.726044] HOOK: 3307528ns - NAME "hook"        <- task creation
(primary mode)
[ 1093.726056] HOOK: 3321275ns - NAME "ROOT/0"
[ 1093.931404] HOOK: 3350018ns - NAME "ROOT/0"
[ 1093.931405] HOOK: 3351297ns - NAME "hook"        <- after the sleep.
The sleep seems to force the task to remain in primary mode during the
cpu load.

I do not think nanosleep(0) suspends the calling task.


[ 1093.931406] HOOK: 208932507ns - NAME "ROOT/0"
[ 1093.931469] HOOK: 209001818ns - NAME "ROOT/0"
[ 1094.930182] HOOK: 1209000982ns - NAME "hook"     <- the task is deleted
[ 1094.930184] HOOK: 1209005156ns - NAME "ROOT/0"
 *
 * case 3 : with the pthread_set_mode_np
 *
[ 1455.427711] HOOK: 123409ns - NAME "ROOT/0"
[ 1455.430896] HOOK: 3311532ns - NAME "hook"      <- task creation
(primary mode)
[ 1455.430908] HOOK: 3325521ns - NAME "ROOT/0"    <- immediate switch in
secondary mode and do cpu load while pthread_set_mode_np
should force the task to remain in primary mode?

Again, how do you see this a switch to secondary mode? The three
sequences look the same to me, I do not see how do you get all these
interpretations.

[ 1455.636262] HOOK: 208942671ns - NAME "ROOT/0"
[ 1455.636331] HOOK: 209015748ns - NAME "ROOT/0"
[ 1456.635043] HOOK: 1209014877ns - NAME "hook"   <- the task is deleted
[ 1456.635045] HOOK: 1209019259ns - NAME "ROOT/0"



-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[alex alex]

linux kernel : 3.2.21
xenomai version : 2.6.2.1
arch: x86

In fact, I base on the cookie of the "rt_task_add_hook" function to
retrieve the descriptor address of the task which has been switched or
started.
And I guess that if the returned name is ROOT it's means that either the
task is switched to secondary mode or it's another linux task and if the
retuned name isn't ROOT it mean that it's a task in the xenomai scheduler.

Also, I deduce the time during which the task "t" has the context by
subtracting  the context switch date of the the task "t+1" by that of the
task "t".
This gives me the following:

*(D) = beginning of the context
*
*(F) = end of the context*

*case 1:*

(D) ROOT/0 : 0.14545 ms : CPU0
(F) ROOT/0 : 3.37748 ms (duree -> 3.23203)
(D) hook : 3.37755 ms : CPU0
(F) hook : 3.38848 ms (duree -> 0.010934)
(D) ROOT/0 : 3.38854 ms : CPU0
(F) ROOT/0 : 208.973 ms (duree -> 205.584)
(D) ROOT/0 : 208.973 ms : CPU0
(F) ROOT/0 : 209.027 ms (duree -> 0.054216)
(D) ROOT/0 : 209.027 ms : CPU0
(F) ROOT/0 : 1209.03 ms (duree -> 1000)
(D) hook : 1209.03 ms : CPU0
(F) hook : 1209.03 ms (duree -> 0.002698)
(D) ROOT/0 : 1209.03 ms : CPU0
(F) ROOT/0 : 1209.03 ms (duree -> 0)
====================================
[ 6858.131530] TRD: 144195ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 6858.134758] TRD: 3374717ns - NOM "hook" - CPU 0 - RT:0
[ 6858.134769] TRD: 3387877ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 6858.340104] TRD: 208971154ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 6858.340157] TRD: 209026676ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 6859.338949] TRD: 1209025602ns - NOM "hook" - CPU 0 - RT:1
[ 6859.338951] TRD: 1209030466ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 6859.339363] TRD: 1209445419ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 6859.339370] TRD: 1209453240ns - NOM "ROOT/0" - CPU 0 - RT:1

*case 2:*

(D) ROOT/0 : 0.141063 ms : CPU0
(F) ROOT/0 : 3.33535 ms (duree -> 3.19428)
(D) hook : 3.33563 ms : CPU0
(F) hook : 3.34731 ms (duree -> 0.011681)
(D) ROOT/0 : 3.34737 ms : CPU0
(F) ROOT/0 : 3.3764 ms (duree -> 0.029035)
(D) ROOT/0 : 3.37646 ms : CPU0
(F) ROOT/0 : 3.37775 ms (duree -> 0.001293)
(D) hook : 3.37779 ms : CPU0
(F) hook : 208.936 ms (duree -> 205.558)
(D) ROOT/0 : 208.936 ms : CPU0
(F) ROOT/0 : 208.997 ms (duree -> 0.06107)
(D) ROOT/0 : 208.997 ms : CPU0
(F) ROOT/0 : 1209 ms (duree -> 1000)
(D) hook : 1209 ms : CPU0
(F) hook : 1209 ms (duree -> 0.003158)
(D) ROOT/0 : 1209 ms : CPU0
(F) ROOT/0 : 1209 ms (duree -> 0)
====================================

[ 7324.095401] TRD: 139711ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7324.098591] TRD: 3333666ns - NOM "hook" - CPU 0 - RT:0
[ 7324.098603] TRD: 3346697ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7324.303943] TRD: 3375854ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7324.303944] TRD: 3377371ns - NOM "hook" - CPU 0 - RT:1
[ 7324.303945] TRD: 208934837ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7324.304002] TRD: 208996555ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7325.302795] TRD: 1208995468ns - NOM "hook" - CPU 0 - RT:1
[ 7325.302797] TRD: 1209000358ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7325.303218] TRD: 1209425068ns - NOM "ROOT/0" - CPU 0 - RT:1
[ 7325.303225] TRD: 1209433203ns - NOM "ROOT/0" - CPU 0 - RT:1

By comparing the two results, I guess when the CPU is loaded, the task is
in secondary mode for the sequence 1 and in primary mode for the sequence 2.


Maybe now it is really clearer...



2013/4/13 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> On 04/13/2013 08:20 PM, alex alex wrote:
>
> > I hope this is more clear like this.
>
>
> We definitely do not have information. As usual, we do not know what
> version of Xenomai you are using, on what platform, how your kernel is
> configured.
>
> /*
>  * When case 1 is activated we see (with the dmesg command) :
>  *
> [  796.318290] HOOK: 107212ns - NAME "ROOT/0"
> [  796.321501] HOOK: 3322158ns - NAME "hook"        <- task creation
> (primary mode)
> [  796.321512] HOOK: 3335024ns - NAME "ROOT/0"      <- immediate switch
> in secondary mode and do cpu load (why this switch?)
>
> 1- a switch from "hook" to "ROOT" thread does not necessarily mean a
> switch to secondary mode. It also happens if "hook" suspends, of if ROOT
> preempts hook.
> 2- a switch to "hook" does not necessarily mean that the task startup is
> done, if you have a look at the thread startup code, you will see that
> has several steps, switching back and forth between the creator task and
> the created task.
> 3- if it is indeed a switch to secondary mode, you can have a look at
> examples/sigdebug.c to see how to find the reason for a secondary mode
> switch.
>
>
> [  796.526870] HOOK: 208957565ns - NAME "ROOT/0"
> [  796.526927] HOOK: 209017235ns - NAME "ROOT/0"
> [  797.525640] HOOK: 1209016502ns - NAME "hook"     <- the task is deleted
> [  797.525642] HOOK: 1209020993ns - NAME "ROOT/0"
>  *
>  * case 2 : with the sleep function
>  *
>  1093.722850] HOOK: 109993ns - NAME "ROOT/0"
> [ 1093.726044] HOOK: 3307528ns - NAME "hook"        <- task creation
> (primary mode)
> [ 1093.726056] HOOK: 3321275ns - NAME "ROOT/0"
> [ 1093.931404] HOOK: 3350018ns - NAME "ROOT/0"
> [ 1093.931405] HOOK: 3351297ns - NAME "hook"        <- after the sleep.
> The sleep seems to force the task to remain in primary mode during the
> cpu load.
>
> I do not think nanosleep(0) suspends the calling task.
>
>
> [ 1093.931406] HOOK: 208932507ns - NAME "ROOT/0"
> [ 1093.931469] HOOK: 209001818ns - NAME "ROOT/0"
> [ 1094.930182] HOOK: 1209000982ns - NAME "hook"     <- the task is deleted
> [ 1094.930184] HOOK: 1209005156ns - NAME "ROOT/0"
>  *
>  * case 3 : with the pthread_set_mode_np
>  *
> [ 1455.427711] HOOK: 123409ns - NAME "ROOT/0"
> [ 1455.430896] HOOK: 3311532ns - NAME "hook"      <- task creation
> (primary mode)
> [ 1455.430908] HOOK: 3325521ns - NAME "ROOT/0"    <- immediate switch in
> secondary mode and do cpu load while pthread_set_mode_np
> should force the task to remain in primary mode?
>
> Again, how do you see this a switch to secondary mode? The three
> sequences look the same to me, I do not see how do you get all these
> interpretations.
>
> [ 1455.636262] HOOK: 208942671ns - NAME "ROOT/0"
> [ 1455.636331] HOOK: 209015748ns - NAME "ROOT/0"
> [ 1456.635043] HOOK: 1209014877ns - NAME "hook"   <- the task is deleted
> [ 1456.635045] HOOK: 1209019259ns - NAME "ROOT/0"
>
>
>
> --
>                                                                 Gilles.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config
Type: application/octet-stream
Size: 147506 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130414/a590eb37/attachment.obj>

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/14/2013 12:41 AM, alex alex wrote:

> linux kernel : 3.2.21
> xenomai version : 2.6.2.1
> arch: x86

>

> In fact, I base on the cookie of the "rt_task_add_hook" function to
> retrieve the descriptor address of the task which has been switched or
> started.
> And I guess that if the returned name is ROOT it's means that either the
> task is switched to secondary mode or it's another linux task and if the
> retuned name isn't ROOT it mean that it's a task in the xenomai scheduler.


Yes, but as I told you ROOT does not necessarily means that a real-time
thread is running in secondary mode.

Also, as I also told you, if you want why a thread switches to secondary
mode, see examples/sigdebug.c

I do not intend to run your example and understand what it does. The way
you try to understand what happens is too indirect and convoluted.

There are simple ways in the application itself, you do not need a
kernel module and a switch hook.

-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/14/2013 01:05 AM, Gilles Chanteperdrix wrote:

> On 04/14/2013 12:41 AM, alex alex wrote:
> 
>> linux kernel : 3.2.21
>> xenomai version : 2.6.2.1
>> arch: x86
> 
>>
> 
>> In fact, I base on the cookie of the "rt_task_add_hook" function to
>> retrieve the descriptor address of the task which has been switched or
>> started.
>> And I guess that if the returned name is ROOT it's means that either the
>> task is switched to secondary mode or it's another linux task and if the
>> retuned name isn't ROOT it mean that it's a task in the xenomai scheduler.
> 
> 
> Yes, but as I told you ROOT does not necessarily means that a real-time
> thread is running in secondary mode.
> 
> Also, as I also told you, if you want why a thread switches to secondary
> mode, see examples/sigdebug.c
> 
> I do not intend to run your example and understand what it does. The way
> you try to understand what happens is too indirect and convoluted.
> 
> There are simple ways in the application itself, you do not need a
> kernel module and a switch hook.


The most exhaustive way being the I-pipe tracer:
http://www.xenomai.org/index.php/I-pipe:Tracer


-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/14/2013 12:41 AM, alex alex wrote:

> linux kernel : 3.2.21
> xenomai version : 2.6.2.1
> arch: x86


BTW, Xenomai is broken on 3.2.21, so moving to 3.4 or 3.5 is recommended.


-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[alex alex]

>There are simple ways in the application itself, you do not need a
>kernel module and a switch hook.

The reason I use a switch hook is to retrieve informations about context
switches to produce a Gantt chart of the sechuleur. But maybe hook
functions are
not suitable for this? Anyway, I'll try to use the tracer with the latest
version of xenomai to try to understand what is happening.

Thank you very much for your replies and advice.


Alex.





2013/4/14 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> On 04/14/2013 12:41 AM, alex alex wrote:
>
> > linux kernel : 3.2.21
> > xenomai version : 2.6.2.1
> > arch: x86
>
>
> BTW, Xenomai is broken on 3.2.21, so moving to 3.4 or 3.5 is recommended.
>
>
> --
>                                                                 Gilles.
>

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 10:47 AM, alex alex wrote:
>> There are simple ways in the application itself, you do not need a
>> kernel module and a switch hook.
>
> The reason I use a switch hook is to retrieve informations about context
> switches to produce a Gantt chart of the sechuleur. But maybe hook
> functions are
> not suitable for this?


Yes, they are, but you should have introduced you mail topic mentioning 
your goal first. The ipipe tracer won't help you in this case.

You should be able to achieve this goal by interposing on the three 
hooks, possibly sending the collected data through a message pipe or 
XDDP socket to a userland app for post-processing.

Hints, for Xenomai 2.6 (-forge works differently):

- scheduler hooks are executed with core lock held, interrupts off: do 
not spend too much time there, or the timings would be affected too much.

- in the SWITCH hook, the following code would tell you whether you are 
looking at a regular linux thread, at a relaxed shadow thread, or at a 
Xenomai thread running in real-time mode, either in userland or kernel 
space:

struct xnthread *me, *t;

me = xnpod_current_thread(); /* this is fine, we are nklock-ed, irqs off */

if (xnthread_test_state(me, XNROOT)) {
	t = xnshadow_thread(current);
	if (t) {
		/* current is shadowed, t is Xenomai's mate, relaxed */
	} else {
		/* current is a regular linux task, no Xenomai shadow */
	}
} else if (xnthread_test_state(me, XNSHADOW)) {
	/* me is a user-space shadow in real-time mode. */
} else {
	/* me is a kernel-based Xenomai thread (always real-time). */
}

-- 
Philippe.

Re: [Xenomai] [QUESTION] thread creation and hook function

[alex alex]

linux kernel : 3.2.21
xenomai version : 2.6.2.1
arch: x86

Thank, I add your code and now I have :

case 1 : ( without nanosleep(0) )

 6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
[ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 - user-space
shadow in real-time mode
[ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux

case 2 : ( with nanosleep(0) before the loop )

[ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
[ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
shadow in real-time mode
[ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 - user-space
shadow in real-time mode
[ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
[ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux

If I follow these outputs, this means that the loop is made by a linux task
and if I add a nanosleep just before, the loop is done by the xenomai task.
Moreover, "hook " switch in primary mode only when it is destroyed unless we
force a primary switch with nanosleep(0) before the loop.

Is a xenomai thread shouldn't start in primary mode or maybe it wait for a
rt service to switch in primary mode?


2013/4/15 Philippe Gerum <rpm@xenomai.org>

> On 04/15/2013 10:47 AM, alex alex wrote:
>
>> There are simple ways in the application itself, you do not need a
>>> kernel module and a switch hook.
>>>
>>
>> The reason I use a switch hook is to retrieve informations about context
>> switches to produce a Gantt chart of the sechuleur. But maybe hook
>> functions are
>> not suitable for this?
>>
>
>
> Yes, they are, but you should have introduced you mail topic mentioning
> your goal first. The ipipe tracer won't help you in this case.
>
> You should be able to achieve this goal by interposing on the three hooks,
> possibly sending the collected data through a message pipe or XDDP socket
> to a userland app for post-processing.
>
> Hints, for Xenomai 2.6 (-forge works differently):
>
> - scheduler hooks are executed with core lock held, interrupts off: do not
> spend too much time there, or the timings would be affected too much.
>
> - in the SWITCH hook, the following code would tell you whether you are
> looking at a regular linux thread, at a relaxed shadow thread, or at a
> Xenomai thread running in real-time mode, either in userland or kernel
> space:
>
> struct xnthread *me, *t;
>
> me = xnpod_current_thread(); /* this is fine, we are nklock-ed, irqs off */
>
> if (xnthread_test_state(me, XNROOT)) {
>         t = xnshadow_thread(current);
>         if (t) {
>                 /* current is shadowed, t is Xenomai's mate, relaxed */
>         } else {
>                 /* current is a regular linux task, no Xenomai shadow */
>         }
> } else if (xnthread_test_state(me, XNSHADOW)) {
>         /* me is a user-space shadow in real-time mode. */
> } else {
>         /* me is a kernel-based Xenomai thread (always real-time). */
> }
>
> --
> Philippe.
>

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 12:25 PM, alex alex wrote:
> linux kernel : 3.2.21
> xenomai version : 2.6.2.1
> arch: x86
>
> Thank, I add your code and now I have :
>
> case 1 : ( without nanosleep(0) )
>
>   6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
> [ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 - user-space
> shadow in real-time mode
> [ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>
> case 2 : ( with nanosleep(0) before the loop )
>
> [ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
> [ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
> shadow in real-time mode
> [ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 - user-space
> shadow in real-time mode
> [ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
> [ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>
> If I follow these outputs, this means that the loop is made by a linux task
> and if I add a nanosleep just before, the loop is done by the xenomai task.
> Moreover, "hook " switch in primary mode only when it is destroyed unless we
> force a primary switch with nanosleep(0) before the loop.
>
> Is a xenomai thread shouldn't start in primary mode

It certainly does.

  or maybe it wait for a
> rt service to switch in primary mode?
>

I can't give you any information. I downloaded your code and can't see 
any "hook" task. There is a "hook" driver, a "tr_sleep" task, but 
nothing else. Besides, your Makefile should use xeno-config for getting 
the proper build flags. Handcrafting this is the fastest path to hell 
with the POSIX skin.

Until I can make sense of the output you mention looking at the actual 
code, I won't be able to help.

/proc/xenomai/sched and /proc/xenomai/stat may help to determine who is 
running, in which mode.

-- 
Philippe.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 02:36 PM, Philippe Gerum wrote:
> On 04/15/2013 12:25 PM, alex alex wrote:
>> linux kernel : 3.2.21
>> xenomai version : 2.6.2.1
>> arch: x86
>>
>> Thank, I add your code and now I have :
>>
>> case 1 : ( without nanosleep(0) )
>>
>>   6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
>> [ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 - user-space
>> shadow in real-time mode
>> [ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>
>> case 2 : ( with nanosleep(0) before the loop )
>>
>> [ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
>> [ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
>> shadow in real-time mode
>> [ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 - user-space
>> shadow in real-time mode
>> [ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>
>> If I follow these outputs, this means that the loop is made by a linux
>> task
>> and if I add a nanosleep just before, the loop is done by the xenomai
>> task.
>> Moreover, "hook " switch in primary mode only when it is destroyed
>> unless we
>> force a primary switch with nanosleep(0) before the loop.
>>
>> Is a xenomai thread shouldn't start in primary mode
>
> It certainly does.
>
>   or maybe it wait for a
>> rt service to switch in primary mode?
>>
>
> I can't give you any information. I downloaded your code and can't see
> any "hook" task. There is a "hook" driver, a "tr_sleep" task, but
> nothing else. Besides, your Makefile should use xeno-config for getting
> the proper build flags. Handcrafting this is the fastest path to hell
> with the POSIX skin.
>
> Until I can make sense of the output you mention looking at the actual
> code, I won't be able to help.
>
> /proc/xenomai/sched and /proc/xenomai/stat may help to determine who is
> running, in which mode.
>

Note: the _get_time() routine in your driver looks broken. In addition, 
calling rtdm_printk services from the hook is strongly discouraged 
unless you don't care for timings.

-- 
Philippe.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 03:05 PM, Philippe Gerum wrote:
> On 04/15/2013 02:36 PM, Philippe Gerum wrote:
>> On 04/15/2013 12:25 PM, alex alex wrote:
>>> linux kernel : 3.2.21
>>> xenomai version : 2.6.2.1
>>> arch: x86
>>>
>>> Thank, I add your code and now I have :
>>>
>>> case 1 : ( without nanosleep(0) )
>>>
>>>   6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
>>> [ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 -
>>> user-space
>>> shadow in real-time mode
>>> [ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>>
>>> case 2 : ( with nanosleep(0) before the loop )
>>>
>>> [ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
>>> [ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
>>> shadow in real-time mode
>>> [ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 -
>>> user-space
>>> shadow in real-time mode
>>> [ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>>
>>> If I follow these outputs, this means that the loop is made by a linux
>>> task
>>> and if I add a nanosleep just before, the loop is done by the xenomai
>>> task.
>>> Moreover, "hook " switch in primary mode only when it is destroyed
>>> unless we
>>> force a primary switch with nanosleep(0) before the loop.
>>>
>>> Is a xenomai thread shouldn't start in primary mode
>>
>> It certainly does.
>>
>>   or maybe it wait for a
>>> rt service to switch in primary mode?
>>>
>>
>> I can't give you any information. I downloaded your code and can't see
>> any "hook" task. There is a "hook" driver, a "tr_sleep" task, but
>> nothing else. Besides, your Makefile should use xeno-config for getting
>> the proper build flags. Handcrafting this is the fastest path to hell
>> with the POSIX skin.
>>
>> Until I can make sense of the output you mention looking at the actual
>> code, I won't be able to help.
>>
>> /proc/xenomai/sched and /proc/xenomai/stat may help to determine who is
>> running, in which mode.
>>
>
> Note: the _get_time() routine in your driver looks broken.

No I'm wrong, it's probably not, assuming the first shot is ok to return 
a close-to-null figure.

  In addition,
> calling rtdm_printk services from the hook is strongly discouraged
> unless you don't care for timings.
>


-- 
Philippe.

Re: [Xenomai] [QUESTION] thread creation and hook function

[alex alex]

Infact, given that the posix skin can not create named task in user space,
the default name which is assigned is the source file name, in this case hook
(hook.c)

I add the changes to have the same ouput and I use xeno-config flag.




2013/4/15 Philippe Gerum <rpm@xenomai.org>

> On 04/15/2013 12:25 PM, alex alex wrote:
>
>> linux kernel : 3.2.21
>> xenomai version : 2.6.2.1
>> arch: x86
>>
>> Thank, I add your code and now I have :
>>
>> case 1 : ( without nanosleep(0) )
>>
>>   6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
>> [ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 - user-space
>> shadow in real-time mode
>> [ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>
>> case 2 : ( with nanosleep(0) before the loop )
>>
>> [ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
>> [ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
>> shadow in real-time mode
>> [ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 - user-space
>> shadow in real-time mode
>> [ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>> [ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>
>> If I follow these outputs, this means that the loop is made by a linux
>> task
>> and if I add a nanosleep just before, the loop is done by the xenomai
>> task.
>> Moreover, "hook " switch in primary mode only when it is destroyed unless
>> we
>> force a primary switch with nanosleep(0) before the loop.
>>
>> Is a xenomai thread shouldn't start in primary mode
>>
>
> It certainly does.
>
>
>  or maybe it wait for a
>
>> rt service to switch in primary mode?
>>
>>
> I can't give you any information. I downloaded your code and can't see any
> "hook" task. There is a "hook" driver, a "tr_sleep" task, but nothing else.
> Besides, your Makefile should use xeno-config for getting the proper build
> flags. Handcrafting this is the fastest path to hell with the POSIX skin.
>
> Until I can make sense of the output you mention looking at the actual
> code, I won't be able to help.
>
> /proc/xenomai/sched and /proc/xenomai/stat may help to determine who is
> running, in which mode.
>
> --
> Philippe.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_switch.tar.bz2
Type: application/x-bzip2
Size: 3504 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130415/e0528953/attachment.bin>

Re: [Xenomai] [QUESTION] thread creation and hook function

[alex alex]

>In addition, calling rtdm_printk services from the hook is strongly
discouraged >unless you don't care for timings.

I use the rtdm_printk just for debugging purpose, in my real application I use
a buffer to store datas.


2013/4/15 alex alex <duch.alexandre@gmail.com>

> Infact, given that the posix skin can not create named task in user space,
> the default name which is assigned is the source file name, in this case hook
> (hook.c)
>
> I add the changes to have the same ouput and I use xeno-config flag.
>
>
>
>
> 2013/4/15 Philippe Gerum <rpm@xenomai.org>
>
>> On 04/15/2013 12:25 PM, alex alex wrote:
>>
>>> linux kernel : 3.2.21
>>> xenomai version : 2.6.2.1
>>> arch: x86
>>>
>>> Thank, I add your code and now I have :
>>>
>>> case 1 : ( without nanosleep(0) )
>>>
>>>   6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
>>> [ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 -
>>> user-space
>>> shadow in real-time mode
>>> [ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>>
>>> case 2 : ( with nanosleep(0) before the loop )
>>>
>>> [ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
>>> [ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
>>> shadow in real-time mode
>>> [ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 -
>>> user-space
>>> shadow in real-time mode
>>> [ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>>
>>> If I follow these outputs, this means that the loop is made by a linux
>>> task
>>> and if I add a nanosleep just before, the loop is done by the xenomai
>>> task.
>>> Moreover, "hook " switch in primary mode only when it is destroyed
>>> unless we
>>> force a primary switch with nanosleep(0) before the loop.
>>>
>>> Is a xenomai thread shouldn't start in primary mode
>>>
>>
>> It certainly does.
>>
>>
>>  or maybe it wait for a
>>
>>> rt service to switch in primary mode?
>>>
>>>
>> I can't give you any information. I downloaded your code and can't see
>> any "hook" task. There is a "hook" driver, a "tr_sleep" task, but nothing
>> else. Besides, your Makefile should use xeno-config for getting the proper
>> build flags. Handcrafting this is the fastest path to hell with the POSIX
>> skin.
>>
>> Until I can make sense of the output you mention looking at the actual
>> code, I won't be able to help.
>>
>> /proc/xenomai/sched and /proc/xenomai/stat may help to determine who is
>> running, in which mode.
>>
>> --
>> Philippe.
>>
>
>

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 03:43 PM, alex alex wrote:
> Infact, given that the posix skin can not create named task in user space,
> the default name which is assigned is the source file name, in this case hook
> (hook.c)

pthread_set_name_np

>
> I add the changes to have the same ouput and I use xeno-config flag.
>
>
>
>
> 2013/4/15 Philippe Gerum <rpm@xenomai.org>
>
>> On 04/15/2013 12:25 PM, alex alex wrote:
>>
>>> linux kernel : 3.2.21
>>> xenomai version : 2.6.2.1
>>> arch: x86
>>>
>>> Thank, I add your code and now I have :
>>>
>>> case 1 : ( without nanosleep(0) )
>>>
>>>    6138.151187] TRD: 394830ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.159924] TRD: 9127501ns - NOM "hook" - CPU 0 - RT:0 - shadow
>>> [ 6138.159953] TRD: 9163835ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.160014] TRD: 370242723ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6138.520008] TRD: 370429306ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521009] TRD: 1370433173ns - NOM "hook" - CPU 0 - RT:1 - user-space
>>> shadow in real-time mode
>>> [ 6139.521014] TRD: 1370446122ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521705] TRD: 1371147808ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6139.521723] TRD: 1371168314ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>>
>>> case 2 : ( with nanosleep(0) before the loop )
>>>
>>> [ 6144.996779] TRD: 382277ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.005024] TRD: 8625148ns - NOM "hook" - CPU 0 - RT:0 - shadow
>>> [ 6145.005054] TRD: 8659990ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.008013] TRD: 8730535ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.008013] TRD: 8734846ns - NOM "hook" - CPU 0 - RT:1 - user-space
>>> shadow in real-time mode
>>> [ 6145.008013] TRD: 367409427ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6145.363763] TRD: 367634768ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.363810] TRD: 1367637465ns - NOM "hook" - CPU 0 - RT:1 - user-space
>>> shadow in real-time mode
>>> [ 6146.363815] TRD: 1367646922ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.365055] TRD: 1368896836ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>> [ 6146.365073] TRD: 1368916343ns - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>>>
>>> If I follow these outputs, this means that the loop is made by a linux
>>> task
>>> and if I add a nanosleep just before, the loop is done by the xenomai
>>> task.
>>> Moreover, "hook " switch in primary mode only when it is destroyed unless
>>> we
>>> force a primary switch with nanosleep(0) before the loop.
>>>
>>> Is a xenomai thread shouldn't start in primary mode
>>>
>>
>> It certainly does.
>>
>>
>>   or maybe it wait for a
>>
>>> rt service to switch in primary mode?
>>>
>>>
>> I can't give you any information. I downloaded your code and can't see any
>> "hook" task. There is a "hook" driver, a "tr_sleep" task, but nothing else.
>> Besides, your Makefile should use xeno-config for getting the proper build
>> flags. Handcrafting this is the fastest path to hell with the POSIX skin.
>>
>> Until I can make sense of the output you mention looking at the actual
>> code, I won't be able to help.
>>
>> /proc/xenomai/sched and /proc/xenomai/stat may help to determine who is
>> running, in which mode.
>>
>> --
>> Philippe.
>>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test_switch.tar.bz2
> Type: application/x-bzip2
> Size: 3504 bytes
> Desc: not available
> URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130415/e0528953/attachment.bin>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
Philippe.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 04:18 PM, alex alex wrote:
> pthread_set_name_np is called after the task creation and it seems that
> the *_np function force to switch in secondary too...

No, it does not. Maybe you should double-check the way you determine 
mode switches.

> Anyway, I'll probably continue to use a rt function to force a created
> task to be in primary mode from the beginning...
>
>
> 2013/4/15 Philippe Gerum <rpm@xenomai.org <mailto:rpm@xenomai.org>>
>
>     On 04/15/2013 03:43 PM, alex alex wrote:
>
>         Infact, given that the posix skin can not create named task in
>         user space,
>         the default name which is assigned is the source file name, in
>         this case hook
>         (hook.c)
>
>
>     pthread_set_name_np
>
>
>         I add the changes to have the same ouput and I use xeno-config flag.
>
>
>
>
>         2013/4/15 Philippe Gerum <rpm@xenomai.org <mailto:rpm@xenomai.org>>
>
>             On 04/15/2013 12:25 PM, alex alex wrote:
>
>                 linux kernel : 3.2.21
>                 xenomai version : 2.6.2.1
>                 arch: x86
>
>                 Thank, I add your code and now I have :
>
>                 case 1 : ( without nanosleep(0) )
>
>                 6138.151187 <tel:6138.151187>] TRD: 394830ns - NOM
>                 "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6138.159924 <tel:%5B%206138.159924>] TRD: 9127501ns -
>                 NOM "hook" - CPU 0 - RT:0 - shadow
>                 [ 6138.159953 <tel:%5B%206138.159953>] TRD: 9163835ns -
>                 NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6138.160014 <tel:%5B%206138.160014>] TRD: 370242723ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6138.520008 <tel:%5B%206138.520008>] TRD: 370429306ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6139.521009 <tel:%5B%206139.521009>] TRD: 1370433173ns
>                 - NOM "hook" - CPU 0 - RT:1 - user-space
>                 shadow in real-time mode
>                 [ 6139.521014 <tel:%5B%206139.521014>] TRD: 1370446122ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6139.521705 <tel:%5B%206139.521705>] TRD: 1371147808ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6139.521723 <tel:%5B%206139.521723>] TRD: 1371168314ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>
>                 case 2 : ( with nanosleep(0) before the loop )
>
>                 [ 6144.996779 <tel:%5B%206144.996779>] TRD: 382277ns -
>                 NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6145.005024 <tel:%5B%206145.005024>] TRD: 8625148ns -
>                 NOM "hook" - CPU 0 - RT:0 - shadow
>                 [ 6145.005054 <tel:%5B%206145.005054>] TRD: 8659990ns -
>                 NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6145.008013 <tel:%5B%206145.008013>] TRD: 8730535ns -
>                 NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6145.008013 <tel:%5B%206145.008013>] TRD: 8734846ns -
>                 NOM "hook" - CPU 0 - RT:1 - user-space
>                 shadow in real-time mode
>                 [ 6145.008013 <tel:%5B%206145.008013>] TRD: 367409427ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6145.363763 <tel:%5B%206145.363763>] TRD: 367634768ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6146.363810 <tel:%5B%206146.363810>] TRD: 1367637465ns
>                 - NOM "hook" - CPU 0 - RT:1 - user-space
>                 shadow in real-time mode
>                 [ 6146.363815 <tel:%5B%206146.363815>] TRD: 1367646922ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6146.365055 <tel:%5B%206146.365055>] TRD: 1368896836ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>                 [ 6146.365073 <tel:%5B%206146.365073>] TRD: 1368916343ns
>                 - NOM "ROOT/0" - CPU 0 - RT:1 - linux
>
>                 If I follow these outputs, this means that the loop is
>                 made by a linux
>                 task
>                 and if I add a nanosleep just before, the loop is done
>                 by the xenomai
>                 task.
>                 Moreover, "hook " switch in primary mode only when it is
>                 destroyed unless
>                 we
>                 force a primary switch with nanosleep(0) before the loop.
>
>                 Is a xenomai thread shouldn't start in primary mode
>
>
>             It certainly does.
>
>
>                or maybe it wait for a
>
>                 rt service to switch in primary mode?
>
>
>             I can't give you any information. I downloaded your code and
>             can't see any
>             "hook" task. There is a "hook" driver, a "tr_sleep" task,
>             but nothing else.
>             Besides, your Makefile should use xeno-config for getting
>             the proper build
>             flags. Handcrafting this is the fastest path to hell with
>             the POSIX skin.
>
>             Until I can make sense of the output you mention looking at
>             the actual
>             code, I won't be able to help.
>
>             /proc/xenomai/sched and /proc/xenomai/stat may help to
>             determine who is
>             running, in which mode.
>
>             --
>             Philippe.
>
>         -------------- next part --------------
>         A non-text attachment was scrubbed...
>         Name: test_switch.tar.bz2
>         Type: application/x-bzip2
>         Size: 3504 bytes
>         Desc: not available
>         URL:
>         <http://www.xenomai.org/__pipermail/xenomai/attachments/__20130415/e0528953/attachment.__bin
>         <http://www.xenomai.org/pipermail/xenomai/attachments/20130415/e0528953/attachment.bin>>
>         _________________________________________________
>         Xenomai mailing list
>         Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>
>         http://www.xenomai.org/__mailman/listinfo/xenomai
>         <http://www.xenomai.org/mailman/listinfo/xenomai>
>
>
>
>     --
>     Philippe.
>
>


-- 
Philippe.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/15/2013 10:47 AM, alex alex wrote:

>> There are simple ways in the application itself, you do not need a
>> kernel module and a switch hook.
> 
> The reason I use a switch hook is to retrieve informations about context
> switches to produce a Gantt chart of the sechuleur. But maybe hook
> functions are
> not suitable for this? Anyway, I'll try to use the tracer with the latest
> version of xenomai to try to understand what is happening.
> 
> Thank you very much for your replies and advice.


The problem is that you will only get partial information. For instance
you will not see context switches which occur between real-time tasks
running in secondary mode.

-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Gilles Chanteperdrix]

On 04/15/2013 04:27 PM, Philippe Gerum wrote:

> On 04/15/2013 04:18 PM, alex alex wrote:
>> pthread_set_name_np is called after the task creation and it seems that
>> the *_np function force to switch in secondary too...
> 
> No, it does not. Maybe you should double-check the way you determine 
> mode switches.


Yes, using SIGDEBUG is the recommended way to understand mode switches.
Anyway, a reason for parasite mode switches could be that Alexandre is
using the 3.2.21 kernel, which we know has issues with mprotect, maybe
he gets additional page faults?


-- 
                                                                Gilles.

Re: [Xenomai] [QUESTION] thread creation and hook function

[Philippe Gerum]

On 04/15/2013 09:45 PM, Gilles Chanteperdrix wrote:
> On 04/15/2013 04:27 PM, Philippe Gerum wrote:
>
>> On 04/15/2013 04:18 PM, alex alex wrote:
>>> pthread_set_name_np is called after the task creation and it seems that
>>> the *_np function force to switch in secondary too...
>>
>> No, it does not. Maybe you should double-check the way you determine
>> mode switches.
>
>
> Yes, using SIGDEBUG is the recommended way to understand mode switches.
> Anyway, a reason for parasite mode switches could be that Alexandre is
> using the 3.2.21 kernel, which we know has issues with mprotect, maybe
> he gets additional page faults?
>
>

In that case he should see reports of forced switches to secondary mode 
in the kernel log, provided CONFIG_XENO_DEBUG_NUCLEUS is enabled.

-- 
Philippe.