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.



Xenomai-core mailing list

Reply via email to