Philippe Gerum wrote: > 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? >
Er, sorry. There's no CONFIG_PREEMPT on Blackfin yet. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
