On 2017-03-14 20:41, Dan Zach wrote: > On Wednesday, 8 March 2017 19:19:36 UTC+2, Dan Zach wrote: >> On Wednesday, 8 March 2017 18:56:43 UTC+2, Dan Zach wrote: >>> On Wednesday, 8 March 2017 18:47:58 UTC+2, J. Kiszka wrote: >>>> On 2017-03-08 17:41, Dan Zach wrote: >>>>> On Wednesday, 8 March 2017 11:48:54 UTC+2, J. Kiszka wrote: >>>>>> On 2017-03-03 17:19, Dan Zach wrote: >>>>>>> On Friday, 3 March 2017 17:38:27 UTC+2, J. Kiszka wrote: >>>>>>>> On 2017-03-03 16:32, Dan Zach wrote: >>>>>>>>> Any observations on the timer list? >>>>>>>>> >>>>>>>> >>>>>>>> Nothing obvious. The only difference is virt vs. phys timer registers, >>>>>>>> but those shouldn't make a difference. I will have to reproduce the >>>>>>>> setup locally. My TK1 is currently out of reach, but the behaviour >>>>>>>> should be ARMv7-generic. >>>>>>>> >>>>>>>> Could you share your non-root RT kernel config? >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> -- >>>>>>>> Siemens AG, Corporate Technology, CT RDA ITP SES-DE >>>>>>>> Corporate Competence Center Embedded Linux >>>>>>> >>>>>>> Please find attached >>>>>>> >>>>>> >>>>>> I was able to reproduce on a Banana Pi, but I didn't debug the root >>>>>> cause yet. Workaround: try to enable CONFIG_ARM_LPAE in the non-root >>>>>> cell kernel config. >>>>>> >>>>>> Jan >>>>>> >>>>>> -- >>>>>> Siemens AG, Corporate Technology, CT RDA ITP SES-DE >>>>>> Corporate Competence Center Embedded Linux >>>>> >>>>> Tried with CONFIG_ARM_LPAE on in the non-root linux. The minimal time is >>>>> still around 40 uS, when the root cell is stressed, worse case is 700us >>>>> >>>> >>>> ...but the cp15 exits are gone? We are seeing a different issue >>>> regarding the latencies then. Tried ftrace already? >>>> >>>> Jan >>>> >>>> -- >>>> Siemens AG, Corporate Technology, CT RDA ITP SES-DE >>>> Corporate Competence Center Embedded Linux >>> >>> The CP15 are down to 20/sec >>> >>> vmexits_total 200708 1019 >>> vmexits_virt_irq 97381 1000 >>> vmexits_cp15 103115 19 >>> vmexits_mmio 207 0 >>> vmexits_psci 3 0 >>> vmexits_management 2 0 >>> vmexits_hypercall 0 0 >>> vmexits_maintenance 0 0 >>> vmexits_virt_sgi 0 0 >>> >>> Still can be the blame for the worth case, but not for the average >>> Could you explain please how LPAE reduced the CP15 exits so dramatically? >> >> With bare-metal gic demo inmate, the jitter is min:3 avg:10 worse:150 >> So the linux is to blame. Any suggestions? > > When the graphics are active, there is an interrupt storm of tegra display > driver: > from /proc/interrupt > 106: 43280 0 0 GIC tegradc.1 > > at rate of ~2KHz. > > When I artificially block this interrupt after a while, I see the real time > jitter behaving almost perfectly. > > > Can you see how interrupt SPI storm ,though to the root cell, might damage RT > jitter on another cell? >
The interrupt storm may be just one symptom of load on shared resources. Maybe the GPU or its driver are also issuing a high load of memory accesses or are otherwise stressing the shared interconnects. Looking at the hypervisor, there should be no interference between two cells if one receives lots of interrupts. Specifically, there is only one shared lock between both in irqchip.c (dist_lock), but it's taken only for a very short read-modify-write access. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
