[Xenomai] "RT throttling" issue

[JK.Behnke at web.de]

   Hello Gilles,

   > in the meanwhile I added rt_timer_tsc as a second alternative to
   measure
   > elapsed time. rt_timer_tsc returns values that are a somewhat greater
   > than expected (around 39 ms instead of expected 20 ms), but still
   > reasonable.
   >
   > > On Thu, Nov 26, 2015 at 11:32:57AM +0100, JK.Behnke at web.de wrote:
   > >> Hello,
   > >>
   > >> in my xenomai 2.6.3 application I sporadically experience very
   long execution times of
   > >> a task that switches back and forth between secondary and primary
   mode.
   > >>
   > >> I added the following code to measure elapsed and cpu time
   > >> //------------- start code snippet ---------------
   > >> struct rusage rsgT1;
   > >> struct rusage rsgT2;
   > >> struct timeval tvT1;
   > >> struct timeval tvT2;
   > >> gettimeofday(&tvT1, NULL);
   > >
   > > Do you observe the same problem with Xenomai 2.6 git head, if you
   > > use clock_gettime(CLOCK_HOST_REALTIME) instead of gettimeofday, at
   > > least for threads running in primary mode ?
   I am now running xenomai 2.6.4 git head.
   The application now uses the posix wrappers as described in the
   documentation "Porting a Linux application to Xenomai dual kernel"
   I replaced the gettimeofday() calls by
   clock_gettime(CLOCK_HOST_REALTIME).
   The getrusage() calls have been removed.

   Both clock_gettime and rt_timer_tsc return reasonable values.
   However, once I observed a loop execution time of 14000 ms instead of
   typical 30 ms.
   This means that the task was blocked for about 14 seconds.
   As I still experience "RT throttling" messages of the Linux kernel,
   I guess that some lengthy operation (file access, memory
   allocation,...)
   of some other task in my application produces the "RT throttling".
   As a side effect the task gets blocked by the Linux scheduler while
   in secondary mode. As mentioned earlier, the task in question switches
   back and forth between secondary and primary mode.

   Is it dangerous to use memory allocation and file access functions
   inside a Linux task running under policy SCHED_FIFO, even though
   they are not really time critical?
   Could some other Linux process block these kind of tasks for such
   a long time (14 sec) or even longer?
   TIA for your comments on this
   Regards
   Jochen