> -----Message d'origine----- > De : Philippe Gerum [mailto:[EMAIL PROTECTED] > Envoyé : mercredi, 26. avril 2006 10:41 > À : ROSSIER Daniel > Cc : [email protected] > 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 _______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
