[Xenomai-help] Scheduling clarification/solution...

[Xenomai-help] Scheduling clarification/solution...

[Tschaeche IT-Services]

Hi,

having done some tests and having read the thread
https://mail.gna.org/public/xenomai-help/2010-04/msg00051.html 
i got the following understanding:

1. Xenomai tasks can be in the state RT and non-RT (relaxed).
   That means: If in RT state, it's scheduled by the Xenomai
   scheduler and if in non-RT state it's scheduled by the
   Linux scheduler.

2. After a Xeno-task did a Linux-Systemcall, e.g. getpid(),
   it will be in non-RT state, raising the Xeno-Root task
   to the priority of Xeno-task (setup by rt_task_shadow()).
   Clearing T_RPIOFF with rt_task_set_mode() disables raising
   priority of the Xeno-Root task when the task is migrating
   from Xenomai RT to Linux non-RT state.

   The Linux scheduler priority of a shadowed Xeno task in
   non-RT state is not touched when migrating from RT -> non-RT.
   Linux scheduling policy and priority depend only on calls
   to sched_setscheduler() pthread_setschedparam() and similar
   Linux/Posix calls. (on the other side Linux/Posix calls
   does not control priority when in RT xenomai state).

   Lazy switching means, that this non-RT Xeno-task will stay
   scheduled by the Linux scheduler until the next Xenomai rt-call.
   This implies, that it may be blocked by other non-RT or
   plain Linux tasks of higher Linux priorities by the
   Linux scheduler while in non-RT state.

3. After a Xeno-task did a Xenomai-Call, e.g. rt-driver call
   or rt_mutex_acquire(), it will be in RT state, scheduled
   by the Xenomai scheduler.

   Lazy switching means, that this RT task will stay scheduled
   by the Xenomai scheduler until the next Linux-System call.

We want a setup with 3 xenomai-shadowed tasks:

  - RT-Task: Running in high priority RT context
  	(Xenomai scheduler, low latency high prio)

  - Cyclic-Task: Running in non-RT context
	(Linux scheduler, prio 0 equal to system services)

  - Background-Task: Running in non-RT context
  	(Linux scheduler, low/IDLE prio)

All of them may acquire shared rt-mutices, which is the reason
for shadowing Cyclic- and Background-task (plain Linux tasks are not
able to acquire an RT-mutex). What we need is:

1. When Cyclic-/Background-task acquires an RT-mutex it migrates
   from Linux to Xenomai scheduler. When releasing the mutex,
   the task should be forced to migrate back to Linux scheduler.

   How to achieve that?

   By calling Linux-Syscall getpid()?

   Is there a Xenomai flag (rt_task_set_mode()) doing that automatically,
   after all RT-resources are released? Which version 2.4.10/2.5.x?

   Do we have to use the patch mentioned in the thread?

2. If Background-task acquires an RT-mutex and is interrupted by RT-task,
   which tries to acquire the same mutex, background inherits RT-tasks
   priority in Xenomai RT context. When background calls to Linux in this
   state, Xenomai-Root task gets RT-task's priority (priority coupling),
   but, because background is scheduled by Linux scheduler now,
   it may be blocked by other non-RT threads running with higher
   Linux priority (e.g. while(1) in cyclic). Is there a method
   in Xenomai to inherit Xenomai-priority to the Linux-scheduler
   settings of a task while the task holds RT resources?

   Is it possible to detect if an RT task calls to Linux while
   holding some RT resources? E.g. a SIGXPU (like for T_WARNSW)
   dependent on acquired RT resources?

   I assume/conclude: While holding RT resources a task must not switch
   to secondary domain. If so, we move control to the Linux scheduler
   loosing RT capabilities. Right?

Best regards and thanks,

	Olli

Re: [Xenomai-help] Scheduling clarification/solution...

[Jan Kiszka]

Tschaeche IT-Services wrote:
> Hi,
> 
> having done some tests and having read the thread
> https://mail.gna.org/public/xenomai-help/2010-04/msg00051.html 
> i got the following understanding:
> 
> 1. Xenomai tasks can be in the state RT and non-RT (relaxed).
>    That means: If in RT state, it's scheduled by the Xenomai
>    scheduler and if in non-RT state it's scheduled by the
>    Linux scheduler.
> 
> 2. After a Xeno-task did a Linux-Systemcall, e.g. getpid(),
>    it will be in non-RT state, raising the Xeno-Root task
>    to the priority of Xeno-task (setup by rt_task_shadow()).
>    Clearing T_RPIOFF with rt_task_set_mode() disables raising
>    priority of the Xeno-Root task when the task is migrating
>    from Xenomai RT to Linux non-RT state.
> 
>    The Linux scheduler priority of a shadowed Xeno task in
>    non-RT state is not touched when migrating from RT -> non-RT.
>    Linux scheduling policy and priority depend only on calls
>    to sched_setscheduler() pthread_setschedparam() and similar
>    Linux/Posix calls. (on the other side Linux/Posix calls
>    does not control priority when in RT xenomai state).
> 
>    Lazy switching means, that this non-RT Xeno-task will stay
>    scheduled by the Linux scheduler until the next Xenomai rt-call.
>    This implies, that it may be blocked by other non-RT or
>    plain Linux tasks of higher Linux priorities by the
>    Linux scheduler while in non-RT state.
> 
> 3. After a Xeno-task did a Xenomai-Call, e.g. rt-driver call
>    or rt_mutex_acquire(), it will be in RT state, scheduled
>    by the Xenomai scheduler.
> 
>    Lazy switching means, that this RT task will stay scheduled
>    by the Xenomai scheduler until the next Linux-System call.
> 
> We want a setup with 3 xenomai-shadowed tasks:
> 
>   - RT-Task: Running in high priority RT context
>   	(Xenomai scheduler, low latency high prio)
> 
>   - Cyclic-Task: Running in non-RT context
> 	(Linux scheduler, prio 0 equal to system services)
> 
>   - Background-Task: Running in non-RT context
>   	(Linux scheduler, low/IDLE prio)
> 
> All of them may acquire shared rt-mutices, which is the reason
> for shadowing Cyclic- and Background-task (plain Linux tasks are not
> able to acquire an RT-mutex). What we need is:
> 
> 1. When Cyclic-/Background-task acquires an RT-mutex it migrates
>    from Linux to Xenomai scheduler. When releasing the mutex,
>    the task should be forced to migrate back to Linux scheduler.
> 
>    How to achieve that?
> 
>    By calling Linux-Syscall getpid()?

That's the workaround for now, true solution is not yet available
(Philippe is on it).

> 
>    Is there a Xenomai flag (rt_task_set_mode()) doing that automatically,
>    after all RT-resources are released? Which version 2.4.10/2.5.x?
> 
>    Do we have to use the patch mentioned in the thread?

That patch is targeting the (now unsupported) 2.4 series. The official
solution will be for 2.5.x or some 2.6.x.

> 
> 2. If Background-task acquires an RT-mutex and is interrupted by RT-task,
>    which tries to acquire the same mutex, background inherits RT-tasks
>    priority in Xenomai RT context. When background calls to Linux in this
>    state, Xenomai-Root task gets RT-task's priority (priority coupling),
>    but, because background is scheduled by Linux scheduler now,
>    it may be blocked by other non-RT threads running with higher
>    Linux priority (e.g. while(1) in cyclic). Is there a method
>    in Xenomai to inherit Xenomai-priority to the Linux-scheduler
>    settings of a task while the task holds RT resources?

No, such a setup is generally considered as a design flaw.

> 
>    Is it possible to detect if an RT task calls to Linux while
>    holding some RT resources? E.g. a SIGXPU (like for T_WARNSW)
>    dependent on acquired RT resources?

CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX + T_WARNSW for the task that must not
suffer from such a prio inversion.

> 
>    I assume/conclude: While holding RT resources a task must not switch
>    to secondary domain. If so, we move control to the Linux scheduler
>    loosing RT capabilities. Right?

Generally right. Syscalls that cannot block on other Linux tasks are an
exception. But that can break when you have to upgrade your kernel.

> 
> Best regards and thanks,
> 
> 	Olli

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Xenomai-help] Forcing a task to run in secondary mode if no RT resources are acquired

[Tschaeche IT-Services]

Hi,

On Tue, May 11, 2010 at 06:20:16PM +0200, Jan Kiszka wrote:
> > 1. When Cyclic-/Background-task acquires an RT-mutex it migrates
> >    from Linux to Xenomai scheduler. When releasing the mutex,
> >    the task should be forced to migrate back to Linux scheduler.
> > 
> >    How to achieve that?
> > 
> >    By calling Linux-Syscall getpid()?
> 
> That's the workaround for now, true solution is not yet available
> (Philippe is on it).
> > 
> >    Is there a Xenomai flag (rt_task_set_mode()) doing that automatically,
> >    after all RT-resources are released? Which version 2.4.10/2.5.x?
> > 
> >    Do we have to use the patch mentioned in the thread?
> 
> That patch is targeting the (now unsupported) 2.4 series. The official
> solution will be for 2.5.x or some 2.6.x.

What we need is a background task running in secondary domain which is able to claim
rt-resources (e.g. xenomai mutices, for synchonisation with RT tasks sending data).
While it's holding maybe multiple resources it should run in primary domain, but when releasing
the last rt resource it should automatically migrate back to secondary domain.

At the moment our solution for that problem would be to hook into each claim/release
function of Xenomai, add a list management to monitor the release of the last resource,
and, if the task does not hold any resource anymore, call a Linux syscall to force migration
to Linux domain.

We would appreciate a proper solution into Xenomai, since Xenomai seems to do
the same in the kernel structures. If we decide to start to patch Xenomai,
we would like to have our changes integrated into Xenomai.
Can you give us a hint to docs for a good starting point (apart from the patch
mentioned above)?

Regards,

	Olli

Re: [Xenomai-help] Scheduling clarification/solution...

[Gilles Chanteperdrix]

Tschaeche IT-Services wrote:
> Hi,
> 
> having done some tests and having read the thread
> https://mail.gna.org/public/xenomai-help/2010-04/msg00051.html 
> i got the following understanding:

You are summarizing stuff explained in Xenomai documentation:
http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf
http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai

To be consistent, when a task is scheduled by Xenomai scheduler, we say
it is in "primary mode", whereas when scheduled by Linux scheduler, we
say it is in "secondary mode". Since this is the terminology we chose,
you would probably better stick to it than using other terms.


> (...)
>    Linux/Posix calls. (on the other side Linux/Posix calls
>    does not control priority when in RT xenomai state).

I do not really understand what you mean. The priorities are fully
propagated between the two schedulers. If you call phtread_setschedparam
or sched_setscheduler, the priority should be propagated to a Xenomai
thread.

-- 
					    Gilles.