RE: Latencies for the Freescale i.MX21/CSB535FS

> -----Message d'origine-----
> De : Philippe Gerum [mailto:rpm@xxxxxxxxxxx]
> Envoyé : mercredi, 26. avril 2006 10:41
> À : ROSSIER Daniel
> Cc : xenomai-core@xxxxxxx
> Objet : Re: [Xenomai-core] 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.

Ok; we will then make further test.

> 
> - 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.
> 

ok; we still have to investigate all the call paths at the Adeos layer before 
the timer reprogramming.

> - 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.
> 
Thanks for the hint; we will spend some time on the tracer in the coming days. 
We keep you informed.

> 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.

Daniel