CAMUS Benoit wrote: > Before all thanks for your advices > > I did some more researches, especially using ipipe tracer. > > First thing that takes me on is IRQ canals: > / # cat /proc/interrupts > CPU0 > 11: 13 SC pxa2xx-i2c > 15: 1143 SC FFUART > 18: 0 SC DMA > 19: 430054 SC PXA Timer Tick > 27: 7335 GPIO eth0 > Err: 0 > > The tick timer seems to have IRQ's level lower than Ethernet once ?
That doesn't change the worst case scenario anyway as long as IRQ handlers can block the execution of all others. > I saw in ipipe code that IRQ from timer doesn't have same process than > others (_ipipe_ack_timerirq and __ipipe_ack_irq). I'm still reading code > to understand this. > > Second is ipipe's trace of max latency path (see file attached), you can > see that shceduling in Linux domain have NMI noise, does it mean taht > it's a non-preempt part ? Nope, something is fishy at least with the tracer. I recall these effects from early ARM patches with tracer support. It should be caused by some reentrancy of the tracer when functions are called insider the tracer core that are not marked as "notrace". Maybe some PXA-specific function to read the TSC? > That could explain a part of latency during http access (ie fork that > infers scheduling). > > So i'm searching for a way in better case, to reduce this latency, in > worst to bound it. > For now i'm looking at interrupt handling code both in Linux, Adeos and > Smc driver to determine if timer IRQ is well masked by Ethernet once and > how to hack it. Let us get the tracer right. Then we would need a full back trace of a frozen path over the detected latency (here: about 900 us). THEN we can see what goes on and what needs a closer look. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
