Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >> >>> Jan Kiszka wrote: >>> >>>> Perrine Martignoni wrote: >>>> >>>> >>>>> Ok. I'll do this. >>>>> >>>>> But I don't understand why the same application compiled without any links >>>>> with Xenomai give different results if there is Xenomai in the kernel. >>>> [Looking at your numbers again] Hmm, maybe some rounding issue of ticks >>>> due to whatever side-effect of I-pipe. We would first of all need the >>>> usual set of information (.config, involved versions) and also >>>> /sys/devices/system/clocksource/clocksource0/current_clocksource. >>> Maybe what Perrine is observing is simply the overhead of the I-pipe ? >>> I mean, Linux is Xenomai idle task, so it is acceptable for Linux >>> numbers to be a bit worse than when Xenomai is not running. >> >> I bit worse is expected. But I think we are seeing 1 or 2 ticks wake-up >> delays here. As far as I understood, they are not due to Xenomai >> consuming significant cycles in the background, are they, Perrine? > > What I see is latencies 5us longer. 5us on ARM is almost nothing, keep > in mind that a simple syscall on ARM already takes 10 us. >
T: 0 ( 732) P:99 I: 10500 C: 2291 Min: 41 Act: 2281 Avg: 5075 Max: 10224 vs. T: 0 ( 893) P:99 I: 10000 C: 1756 Min: 13407 Act: 13536 Avg: 13452 Max: 13693 Thus the _minimum_ and the _average_ wakeup time of a Linux task increase fairly significant here. That's the point. Given a reasonable runtime of both test, this /could/ be considered as a regression of a Xenomai-enabled Linux kernel. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
