Re: [Xenomai-help] Preemptive scheduling

["Jack Whorn" <jackwhorn@domain.hid>]

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