ROSSIER Daniel wrote:
Hi all,
As promised, you can find the latency results (latency –t0/-t1/-t2) as
well as the
stats from the switch utility for the performance of our Xenomai port
onto the i.MX21 board.
These are fesh results J and we didn't have time to analyze them yet.
Thanks for any feedback…
The tests have not been run long enough under load to get a reliable
measure of the real worst-case figures, but still, the data sets seem
consistent.
- the test run of latency -t2 (in-kernel timer handler) shows equivalent
worst-case figures than the -t1 form (in-kernel thread), which means
that most of the latency hit is taken at the Adeos level, i.e. in-kernel
scheduling adds little in the picture. Room for improvement is primarily
hiding somewhere in the Adeos layer, I think.
- comparing the min latency observed in the -t1 and -t2 forms, it looks
like the inherent cost of traversing the rescheduling path would be
close to ~10 us.
- comparing the min latency observed in the -t0 and -t1 forms, there is
another 10+ us consumed in switching mm contexts, and paying the
involved cache penalties. The way to measure the level of perturbation
Linux adds by switching its own tasks is to write a simple kernel module
embodying a Xenomai thread that keeps the CPU busy while the performance
test is running at a higher priority.
I'd say that the most efficient way to reduce those latencies would
require to first identify the source of the 40+ us spot observed with
the -t2 form on an idle system. For that, I'm convinced that porting the
I-pipe tracer to ARM would be the best option, since this tool would be
of great help there.
This port basically requires 1) to code the mcount() routine supporting
gcc's -pg option, 2) to solve early boot issues so that mcount() does
not attempt to trace anything while the memory environment has not been
fully set up. The rest is pretty generic.
--
Philippe.
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
