[Xenomai-help] Preemptive scheduling

[Xenomai-help] Preemptive scheduling

[Jack Whorn]

Hi,

I`m new to Xenomai and I`m experiencing some issues.

Why does a Xenomai thread (native skin) with an infinite loop hang the system, though there are higher-priority RT-threads present, and
rt_task_set_mode periodically clears T_LOCK and T_SHIELD and sets T_RRB?

Isn`t the scheduler preemptive, first considering the thread`s priority and subsequently the thread`s position in its priority`s ready queue?

I have attached some sample code.

Thanks for any hint,

Jack


#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <sys/time.h>
#include <sys/io.h>
#include <sys/mman.h>
#include <sys/types.h>

#include <native/task.h>
#include <native/queue.h>
#include <native/intr.h>
#include <native/timer.h>


#define STACK_SIZE 8192
#define PRIO 10


static RT_TASK timer_task_desc;

//		              ..s.ms.µs.ns
static RTIME task_period_ns =   0100000000llu;

static unsigned long overruns = 0;

static void clean_exit(int dummy) {

  rt_task_delete(&timer_task_desc);

}

static void thread(void *cookie) {

  int ret;
  int i;
  int c;


  ret = rt_task_set_mode(T_LOCK, T_RRB, &c);
  if (ret)
    return;

  ret = rt_task_set_periodic(NULL, TM_NOW, rt_timer_ns2ticks(task_period_ns));
  if (ret)
    return;

  while (1) {
    
    ret = rt_task_set_mode(T_LOCK | T_SHIELD, T_RRB | T_PRIMARY, NULL);
    if (ret)
      return;

    ret = rt_task_wait_period(&overruns);
    if (ret == -ETIMEDOUT) {
    } else if (ret) {
      clean_exit(0);
    }

    while (1);	/* infinite loop */

  }
  kill(0, SIGTERM);
}


int main(int argc, char** argv) {

  int err;

  signal(SIGTERM, clean_exit);
  signal(SIGINT, clean_exit);

  mlockall(MCL_CURRENT | MCL_FUTURE);

  err = rt_task_spawn(&timer_task_desc, "thread", STACK_SIZE, PRIO, 0, &thread, NULL);
  if (err)
    return 0;

  pause();

  return EXIT_SUCCESS;

}
-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [Xenomai-help] Preemptive scheduling

[Gilles Chanteperdrix]

Jack Whorn wrote:
 > Hi,
 > 
 > I`m new to Xenomai and I`m experiencing some issues.
 > 
 > Why does a Xenomai thread (native skin) with an infinite loop hang the system, though there are higher-priority RT-threads present, and
 > rt_task_set_mode periodically clears T_LOCK and T_SHIELD and sets T_RRB?
 > 
 > Isn`t the scheduler preemptive, first considering the thread`s priority and subsequently the thread`s position in its priority`s ready queue?
 > 
 > I have attached some sample code.
 > 
 > Thanks for any hint,
 > 
 > Jack
 > 
 > 
 > #include <stdio.h>
 > #include <unistd.h>
 > #include <stdlib.h>
 > #include <signal.h>
 > #include <string.h>
 > #include <sys/time.h>
 > #include <sys/io.h>
 > #include <sys/mman.h>
 > #include <sys/types.h>
 > 
 > #include <native/task.h>
 > #include <native/queue.h>
 > #include <native/intr.h>
 > #include <native/timer.h>
 > 
 > 
 > #define STACK_SIZE 8192
 > #define PRIO 10
 > 
 > 
 > static RT_TASK timer_task_desc;
 > 
 > //		              ..s.ms.µs.ns
 > static RTIME task_period_ns =   0100000000llu;
 > 
 > static unsigned long overruns = 0;
 > 
 > static void clean_exit(int dummy) {
 > 
 >   rt_task_delete(&timer_task_desc);
 > 
 > }
 > 
 > static void thread(void *cookie) {
 > 
 >   int ret;
 >   int i;
 >   int c;
 > 
 > 
 >   ret = rt_task_set_mode(T_LOCK, T_RRB, &c);
 >   if (ret)
 >     return;
 > 
 >   ret = rt_task_set_periodic(NULL, TM_NOW, rt_timer_ns2ticks(task_period_ns));
 >   if (ret)
 >     return;
 > 
 >   while (1) {
 >     
 >     ret = rt_task_set_mode(T_LOCK | T_SHIELD, T_RRB | T_PRIMARY, NULL);
 >     if (ret)
 >       return;
 > 
 >     ret = rt_task_wait_period(&overruns);
 >     if (ret == -ETIMEDOUT) {
 >     } else if (ret) {
 >       clean_exit(0);
 >     }
 > 
 >     while (1);	/* infinite loop */

Once your program enters this infinte loop, it never gets out, so :
- your assumption that "t_task_set_mode periodically clears T_LOCK and
  T_SHIELD and sets T_RRB" is false;
- even if higher priority task runs, Linux, which is Xenomai idle task
  never runs, so the system locks up.

In short, maybe you have observed some scheduling problems, but your
example does not demonstrate them. Such misuse of Xenomai should be
caught by the watchdog, if you enable it.


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Preemptive scheduling

[Jack Whorn]

Hi Gilles,

> Once your program enters this infinte loop, it never gets out, so :
> - your assumption that "t_task_set_mode periodically clears T_LOCK and
>   T_SHIELD and sets T_RRB" is false;

Yeah, I just realized that it does this only once. According to http://snail.fsffrance.org/www.xenomai.org/documentation/branches/v2.0.x/html/api/group__task.html#ga44But I think that the arguments used in the rt_task_set_mode() -call are correct. Isn't that sufficient for the Linux OS to catch e.g. keyboard interrupts?

> - even if higher priority task runs, Linux, which is Xenomai idle task
>   never runs, so the system locks up.

Gotcha, that sounds sensible to me.

Actually, the higher-priority task uses some linux-system calls to store data to hard disk. This does no longer take place as soon as the infinite loop is entered. I expected priority coupling to solve that. Where is my error in reasoning?

> In short, maybe you have observed some scheduling problems, but your
> example does not demonstrate them. Such misuse of Xenomai should be
> caught by the watchdog, if you enable it.

I might try that watchdog, thanks for this hint!

Regards,

Jack
-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

Re: [Xenomai-help] Preemptive scheduling

[Gilles Chanteperdrix]

Jack Whorn wrote:
> Hi Gilles,
> 
> 
>>Once your program enters this infinte loop, it never gets out, so :
>>- your assumption that "t_task_set_mode periodically clears T_LOCK and
>>  T_SHIELD and sets T_RRB" is false;
> 
> 
> Yeah, I just realized that it does this only once. According to http://snail.fsffrance.org/www.xenomai.org/documentation/branches/v2.0.x/html/api/group__task.html#ga44But I think that the arguments used in the rt_task_set_mode() -call are correct. Isn't that sufficient for the Linux OS to catch e.g. keyboard interrupts?
> 
> 
>>- even if higher priority task runs, Linux, which is Xenomai idle task
>>  never runs, so the system locks up.
> 
> 
> Gotcha, that sounds sensible to me.
> 
> Actually, the higher-priority task uses some linux-system calls to store data to hard disk. This does no longer take place as soon as the infinite loop is entered. I expected priority coupling to solve that. Where is my error in reasoning?

Maybe storing data to the disk requires a kernel thread to flush them.
If this thread never has a chance to run, then your data are written in
the cache but never flushed to the disk. I may be wrong, but I am almost
sure that if you let Linux run, everything will go as expected.

If I am wrong, please, send us a self-contained example program which
demonstrates the behaviour you observed.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Preemptive scheduling

[Jack Whorn]

Hi Gilles, Hi folks,

The data is stored by a thread that periodically issues a single call to
rt_task_set_mode(0, T_PRIMARY, NULL) followed by several file operation calls like fprintf() and finally a call to fflush(NULL) and sync().

The application is not a kernel module, so - as far as I see it - it is a user mode thread, and it actually has the highest priority in my system.

Does this help understanding the phenomenon?

Regards,

Jack

> Jack Whorn wrote:
> > Hi Gilles,
> > 
> > 
> >>Once your program enters this infinte loop, it never gets out, so :
> >>- your assumption that "t_task_set_mode periodically clears T_LOCK and
> >>  T_SHIELD and sets T_RRB" is false;
> > 
> > 
> > Yeah, I just realized that it does this only once. According to
> http://snail.fsffrance.org/www.xenomai.org/documentation/branches/v2.0.x/html/api/group__task.html#ga44But
> I think that the arguments used in the rt_task_set_mode() -call are
> correct. Isn't that sufficient for the Linux OS to catch e.g. keyboard
> interrupts?
> > 
> > 
> >>- even if higher priority task runs, Linux, which is Xenomai idle task
> >>  never runs, so the system locks up.
> > 
> > 
> > Gotcha, that sounds sensible to me.
> > 
> > Actually, the higher-priority task uses some linux-system calls to store
> data to hard disk. This does no longer take place as soon as the infinite
> loop is entered. I expected priority coupling to solve that. Where is my
> error in reasoning?
> 
> Maybe storing data to the disk requires a kernel thread to flush them.
> If this thread never has a chance to run, then your data are written in
> the cache but never flushed to the disk. I may be wrong, but I am almost
> sure that if you let Linux run, everything will go as expected.
> 
> If I am wrong, please, send us a self-contained example program which
> demonstrates the behaviour you observed.
> 
> -- 
>                                                  Gilles Chanteperdrix

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [Xenomai-help] Preemptive scheduling

[Philippe Gerum]

On Tue, 2007-04-03 at 22:05 +0200, Jack Whorn wrote:
> Hi Gilles, Hi folks,
> 
> The data is stored by a thread that periodically issues a single call to
> rt_task_set_mode(0, T_PRIMARY, NULL) followed by several file operation calls like fprintf() and finally a call to fflush(NULL) and sync().
> 
> The application is not a kernel module, so - as far as I see it - it is a user mode thread, and it actually has the highest priority in my system.
> 
> Does this help understanding the phenomenon?
> 

This whole thing reminds me of an issue involving T_LOCK that existed
for any version earlier than 2.3.1. The way the scheduler lock (i.e.
T_LOCK) was managed at that time would cause unexpectable results (aka
"utter mess") to happen whenever a scheduler lock holder thread switches
to secondary mode, and thinking about it, this would surely cause a
lockup due to a scheduling wreckage. This has been fixed on January 30,
by allowing the currently running thread which holds the scheduler lock
to sleep.

You may want to try 2.3.1 to check this.

-- 
Philippe.

Re: [Xenomai-help] Preemptive scheduling

[Jack Whorn]

Hi Philippe,

thank you for this suggestion!

You are right, I`m  still using version 2.3. This is due to some adjustments I have made in the Xenomai Sources which prevent me from simply overwriting the old files.

I have just locked at the source-code, the only occasion I use T_LOCK is in the rt_task_set_mode() call, used as the first argument (clear mask!). So there should not be a T_LOCK at all.

Nevertheless, if anybody could provide me with the appropriate positions in Xenomai`s source code, I might apply this bugfix manually and find out whether the problem is solved this way.

Thank you very much,

Jack


-------- Original-Nachricht --------
Datum: Tue, 03 Apr 2007 22:24:35 +0200
Von: Philippe Gerum <rpm@xenomai.org>
An: Jack Whorn <jackwhorn@domain.hid>
CC: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>, xenomai@xenomai.org
Betreff: Re: [Xenomai-help] Preemptive scheduling

> On Tue, 2007-04-03 at 22:05 +0200, Jack Whorn wrote:
> > Hi Gilles, Hi folks,
> > 
> > The data is stored by a thread that periodically issues a single call to
> > rt_task_set_mode(0, T_PRIMARY, NULL) followed by several file operation
> calls like fprintf() and finally a call to fflush(NULL) and sync().
> > 
> > The application is not a kernel module, so - as far as I see it - it is
> a user mode thread, and it actually has the highest priority in my system.
> > 
> > Does this help understanding the phenomenon?
> > 
> 
> This whole thing reminds me of an issue involving T_LOCK that existed
> for any version earlier than 2.3.1. The way the scheduler lock (i.e.
> T_LOCK) was managed at that time would cause unexpectable results (aka
> "utter mess") to happen whenever a scheduler lock holder thread switches
> to secondary mode, and thinking about it, this would surely cause a
> lockup due to a scheduling wreckage. This has been fixed on January 30,
> by allowing the currently running thread which holds the scheduler lock
> to sleep.
> 
> You may want to try 2.3.1 to check this.
> 
> -- 
> Philippe.
> 

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [Xenomai-help] Preemptive scheduling

[Philippe Gerum]

On Tue, 2007-04-03 at 22:55 +0200, Jack Whorn wrote:
> Hi Philippe,
> 
> thank you for this suggestion!
> 
> You are right, I`m  still using version 2.3. This is due to some adjustments I have made in the Xenomai
>  Sources which prevent me from simply overwriting the old files.
> 
> I have just locked at the source-code, the only occasion I use T_LOCK is in the rt_task_set_mode() call,
>  used as the first argument (clear mask!). So there should not be a T_LOCK at all.
> 
> Nevertheless, if anybody could provide me with the appropriate positions in Xenomai`s source code,
>  I might apply this bugfix manually and find out whether the problem is solved this way.
> 

Changeset r2092 introduced the sleeping scheduler lock for v2.3.x.

> Thank you very much,
> 
> Jack
> 
> 
> -------- Original-Nachricht --------
> Datum: Tue, 03 Apr 2007 22:24:35 +0200
> Von: Philippe Gerum <rpm@xenomai.org>
> An: Jack Whorn <jackwhorn@domain.hid>
> CC: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>, xenomai@xenomai.org
> Betreff: Re: [Xenomai-help] Preemptive scheduling
> 
> > On Tue, 2007-04-03 at 22:05 +0200, Jack Whorn wrote:
> > > Hi Gilles, Hi folks,
> > > 
> > > The data is stored by a thread that periodically issues a single call to
> > > rt_task_set_mode(0, T_PRIMARY, NULL) followed by several file operation
> > calls like fprintf() and finally a call to fflush(NULL) and sync().
> > > 
> > > The application is not a kernel module, so - as far as I see it - it is
> > a user mode thread, and it actually has the highest priority in my system.
> > > 
> > > Does this help understanding the phenomenon?
> > > 
> > 
> > This whole thing reminds me of an issue involving T_LOCK that existed
> > for any version earlier than 2.3.1. The way the scheduler lock (i.e.
> > T_LOCK) was managed at that time would cause unexpectable results (aka
> > "utter mess") to happen whenever a scheduler lock holder thread switches
> > to secondary mode, and thinking about it, this would surely cause a
> > lockup due to a scheduling wreckage. This has been fixed on January 30,
> > by allowing the currently running thread which holds the scheduler lock
> > to sleep.
> > 
> > You may want to try 2.3.1 to check this.
> > 
> > -- 
> > Philippe.
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Preemptive scheduling

[Jack Whorn]

> Changeset r2092 introduced the sleeping scheduler lock for v2.3.x.

Hi Philippe,

I appreciate your help very much! I found and applied the diffs of changeset r2092. It seems to work much better now: The system is able to access the hard disk, as I see the LED blinking periodically. That`s great!

Still, I can`t use the keyboard to stop the application by pressing Strg-C. Also, the text cursor doesn`t blink, so the Linux system seems to be overloaded (probably, it`s no longer scheduled).

So, the Linux-Kernel now seems to be able to run on behalf of a high-priority task. Though, it is no longer scheduled as an idle task, which is ok as there is the higher priority-task with the infinite loop. This way, everything acts as expected.

Nevertheless, it would be interesting to run a linux shell concurrently. Can I adjust linux priority during runtime (or: where do I have to adjust it in the sources)?

And btw, where can I look up the keyboard interrupt`s priority (is it kernel`s priority)?

Thanks a lot,

Jack

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [Xenomai-help] Preemptive scheduling

[Philippe Gerum]

On Wed, 2007-04-04 at 17:10 +0200, Jack Whorn wrote:
> > Changeset r2092 introduced the sleeping scheduler lock for v2.3.x.
> 
> Hi Philippe,
> 
> I appreciate your help very much! I found and applied the diffs of changeset r2092.
>  It seems to work much better now: The system is able to access the hard disk, as I
>  see the LED blinking periodically. That`s great!
> 
> Still, I can`t use the keyboard to stop the application by pressing Strg-C.
> Also, the text cursor doesn`t blink, so the Linux system seems to be overloaded
>  (probably, it`s no longer scheduled).
> 
> So, the Linux-Kernel now seems to be able to run on behalf of a high-priority task.
>  Though, it is no longer scheduled as an idle task, which is ok as there is the highe
> r priority-task with the infinite loop. This way, everything acts as expected.
> 

What you see is your real-time task called "thread" running, nothing
else.

> Nevertheless, it would be interesting to run a linux shell concurrently. Can I adjust
>  linux priority during runtime (or: where do I have to adjust it in the sources)?
> 
> And btw, where can I look up the keyboard interrupt`s priority (is it kernel`s priority)?
> 

You may want to read these articles, explaining the basic concept of
primary and secondary domains as seen by the native API and all other
interfaces, and how this is implementing by the Adeos layer:
http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf
http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf

In short, the infinite loop inside your application runs in primary
mode, which starves the regular Linux kernel from CPU and interrupts, so
that primary mode remains highly predictable time-wise. For that reason,
hitting ^C has no effect when running this loop (no kbd IRQ and no input
core polling for kbd event => no driver interaction => no termio
handling => no SIGINT ever emitted therefore received by your process).
All the CPU is eaten by your thread, and only real-time interrupts are
allowed to preempt it from time to time.
(Activating CONFIG_XENO_OPT_WATCHDOG would pull the break and stop this
loop after 4s btw).

You cannot adjust the kernel priority in the Xenomai scale yourself,
this would introduce unpredictable latencies. Xenomai does a similar
adjustment automatically when a real-time switches to secondary mode (an
explanation can be found in the cited docs), but this could be applied
to any random Linux task without wrecking the real-time behaviour, so
this has not been made possible.

To sum up, if you want regular I/O such as keyboard input to be
processed by Linux, you need to leave a bit of CPU time to the regular
kernel. This is why the infinite loop seems to lock up the box.

Rule of thumb: this is not a pure RTOS, but a combo merging a GPOS and a
RTOS sub-system to get the best of both worlds, so you need to make sure
that both can co-exist together - which does not prevent to one a higher
priority over the other - and leaving CPU time to the regular kernel to
process regular I/O through normal drivers is part of the requirements.
It is possible to develop real-time I/O drivers (RTDM is there for this
task), in this case, most of their code is controlled in primary mode by
Xenomai, and not by the vanilla Linux kernel.

> Thanks a lot,
> 
> Jack
> 
-- 
Philippe.

Re: [Xenomai-help] Preemptive scheduling

[Jack Whorn]

Hi Philippe,

Thanks a lot for this information!

This watchdog is great. I just tried and it successfully stopped my application. Nice to see!

At this point, I have a short question:

As far as I have seen, Xenomai`s watchdog kills the currently running task when wd_count (which is increased every second) has reached 4. But when is wd_count reset? I have only seen wd_count being reset to zero whenever Linux is scheduled. I don`t understand how this can be sufficient (which obviously is!), as I had expected it being reset whenever *any* task is rescheduled. How can the system know that it is the currently running task that has prevented Linux from being scheduled?

Thanks for giving me a hint on this,

Jack

-------- Original-Nachricht --------
Datum: Thu, 05 Apr 2007 20:38:57 +0200
Von: Philippe Gerum <rpm@xenomai.org>
An: Jack Whorn <jackwhorn@domain.hid>
CC: xenomai@xenomai.org
Betreff: Re: [Xenomai-help] Preemptive scheduling

> On Wed, 2007-04-04 at 17:10 +0200, Jack Whorn wrote:
> > > Changeset r2092 introduced the sleeping scheduler lock for v2.3.x.
> > 
> > Hi Philippe,
> > 
> > I appreciate your help very much! I found and applied the diffs of
> changeset r2092.
> >  It seems to work much better now: The system is able to access the hard
> disk, as I
> >  see the LED blinking periodically. That`s great!
> > 
> > Still, I can`t use the keyboard to stop the application by pressing
> Strg-C.
> > Also, the text cursor doesn`t blink, so the Linux system seems to be
> overloaded
> >  (probably, it`s no longer scheduled).
> > 
> > So, the Linux-Kernel now seems to be able to run on behalf of a
> high-priority task.
> >  Though, it is no longer scheduled as an idle task, which is ok as there
> is the highe
> > r priority-task with the infinite loop. This way, everything acts as
> expected.
> > 
> 
> What you see is your real-time task called "thread" running, nothing
> else.
> 
> > Nevertheless, it would be interesting to run a linux shell concurrently.
> Can I adjust
> >  linux priority during runtime (or: where do I have to adjust it in the
> sources)?
> > 
> > And btw, where can I look up the keyboard interrupt`s priority (is it
> kernel`s priority)?
> > 
> 
> You may want to read these articles, explaining the basic concept of
> primary and secondary domains as seen by the native API and all other
> interfaces, and how this is implementing by the Adeos layer:
> http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf
> http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf
> 
> In short, the infinite loop inside your application runs in primary
> mode, which starves the regular Linux kernel from CPU and interrupts, so
> that primary mode remains highly predictable time-wise. For that reason,
> hitting ^C has no effect when running this loop (no kbd IRQ and no input
> core polling for kbd event => no driver interaction => no termio
> handling => no SIGINT ever emitted therefore received by your process).
> All the CPU is eaten by your thread, and only real-time interrupts are
> allowed to preempt it from time to time.
> (Activating CONFIG_XENO_OPT_WATCHDOG would pull the break and stop this
> loop after 4s btw).
> 
> You cannot adjust the kernel priority in the Xenomai scale yourself,
> this would introduce unpredictable latencies. Xenomai does a similar
> adjustment automatically when a real-time switches to secondary mode (an
> explanation can be found in the cited docs), but this could be applied
> to any random Linux task without wrecking the real-time behaviour, so
> this has not been made possible.
> 
> To sum up, if you want regular I/O such as keyboard input to be
> processed by Linux, you need to leave a bit of CPU time to the regular
> kernel. This is why the infinite loop seems to lock up the box.
> 
> Rule of thumb: this is not a pure RTOS, but a combo merging a GPOS and a
> RTOS sub-system to get the best of both worlds, so you need to make sure
> that both can co-exist together - which does not prevent to one a higher
> priority over the other - and leaving CPU time to the regular kernel to
> process regular I/O through normal drivers is part of the requirements.
> It is possible to develop real-time I/O drivers (RTDM is there for this
> task), in this case, most of their code is controlled in primary mode by
> Xenomai, and not by the vanilla Linux kernel.
> 
> > Thanks a lot,
> > 
> > Jack
> > 
> -- 
> Philippe.
> 

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: [Xenomai-help] Preemptive scheduling

[Dmitry Adamushko]

On 11/04/07, Jack Whorn <jackwhorn@domain.hid> wrote:
> [...]
> As far as I have seen, Xenomai`s watchdog kills the currently running task when >wd_count (which is increased every second) has reached 4. But when is wd_count >reset? I have only seen wd_count being reset to zero whenever Linux is scheduled. I >don`t understand how this can be sufficient (which obviously is!), as I had expected it >being reset whenever *any* task is rescheduled. How can the system know that it is >the currently running task that has prevented Linux from being scheduled?
>

The comment in xnpod_watchdog_handler() is a bit misleading.

The idea is to avoid starvation of the linux kernel for more than 4
seconds, right. But this starvation can be well done either by one rt
task or a few which are running one by one. The watchdog will kill the
one that happens to run at 4-th second.

e.g. 2 tasks : task1 takes 3.98 s. and then task2 - just 0.05 second.
The watchdog handler will shoot task2, although the real problem is
task1.

Nevertheless, for the majority of cases, this problem happens when
some rt task is misbehaving (say, an endless loop under some
circumstances) and - the one that gets killed - is the one that
monopolise the CPU indeed.


-- 
Best regards,
Dmitry Adamushko