Re: Latencies for the Freescale i.MX21/CSB535FS

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.