Re: [Xenomai-help] Will Linux kernel lose timer ticks when RT thread is running

[Philippe Gerum <rpm@xenomai.org>]

Li Yi (Adam) wrote:
> Hi,
>  
> When a real-time thread is running, the Linux kernel will lose Timer 
> Tick (and lose timer interrupts), is this the expected behavior?
>  

No, it should not lose any tick, regardless of the Xenomai port. You are
likely observing a pecularity of the Blackfin port where Adeos moves
Linux IRQ handlers (top-halves) in thread context to work-around a high
scheduling latency source which is Blackfin specific.

> If yes, in this case,  no interrupts will be passed to Linux domain? 
> This may cause some services depending on timing in Linux domain do not 
> work correctly. In another thread I read:
>  
> "
> I do not know if it is what you mean, but when running Xenomai, your
> tasks are supposed to suspend sufficiently frequently to leave Linux
> tick normally. This means that if you configured CONFIG_HZ=100, your
> real-time activity (including kernel-space tasks and user-space tasks in
> primary mode) is supposed to take a break at least once every 1/100
> second.
> --
>                                            Gilles Chanteperdrix.  
> "
> Is this the best solution? Since there may be possibility that a 
> real-time thread keep running for severl hundred ms (e.g, processing 
> large block of data).
>  

Keep in mind that real-time using a co-scheduling infrastructure in
Linux is not a matter of pure RTOS design, but rather an issue involving
 a GPOS+RTOS combination. For this reason, you just should not starve
the GPOS from the critical resources it needs, and time ticks are some
of these. If you do so though, what will happen is that the ticks will
be logged at Adeos level in the various pipeline logs, and played when
Linux eventually gets back in control as the active Adeos domain. If the
starvation did not last beyond Linux's robustness to such event, then
the kernel will catch up with the pending ticks and the system will
continue normally. IOW, it's not impossible to do lengthy real-time
processing that might delay/unsynchronize Linux ticks, and this might
work properly if some breathing time is left to the kernel, but you
cannot ask the real-time system to drop the determinism just for the
sake of allowing Linux to tick regularly. It's up to the application
designer to properly evaluate the real-time load which is going to be
bearable by the underlying architecture & kernel combo.

In the particular case of multi-ms processing, I would likely suggest to
move it to a thread running in secondary mode without interrupt
shielding, so that Linux asynchronous activities such as interrupt
handling would still be possible, at the expense of a lesser execution
time predictability of such processing though.

>  
> I tried to run a test on Xenomai-2.1.0 on Blackfin. This test looks like:
>  

<snip>


> +++++++++ end test +++++++++++++++++
> 
>  From the test result, " 23:  BFIN Timer Tick", changed from "33531" to
> "33732", that is "201 * 10 ＝ 2010 ms". And the "up time" is changed
> from "335.41 to 337.42", although in fact that "2 + 6 = 8 sec" has
> passed.
>

You may want to make your measurement thread sleep() for a while before
looking at the final tick counter; this would make sure that the IRQ
threads have been given enough time to catch up and process all pending
ticks they have in their log. Btw, did you activate CONFIG_PREEMPT?

-- 

Philippe.