On 2017-06-26 18:26, Gustavo Lima Chaves wrote: > * Henning Schild <[email protected]> [2017-06-26 09:55:59 +0200]: > >> Am Fri, 23 Jun 2017 14:56:58 -0700 >> schrieb Gustavo Lima Chaves <[email protected]>: >> >>> * Jan Kiszka <[email protected]> [2017-06-23 22:36:35 +0200]: >>> >>>> On 2017-06-23 19:33, Gustavo Lima Chaves wrote: >>>>> [...] >>>>> >>>>>>> >>>>>>> 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 >>>>> >>>>> What about Linux inmate cells on Intel? Has anybody else seem >>>>> horrid timer resolutions (like ".resolution: 1000000 nsecs") as >>>>> well? The aforementioned ARM patch makes no sense for the x86's >>>>> version of time.c, I guess. Should we be providing HPET address >>>>> to the inmate the same way it's done for PM timer address? Any >>>>> other ideas? >>>> >>>> What's your setup exactly? >>> >>> Maybe it's something in my inmate Linux config? I've tried with two >>> codebases there: RT Linux and upstream (both with Jailhouse patches, >>> naturally). I'll attach one of the configs. >>> >>>> >>>> There is no need to use the slow HPET on x86 anymore, with or >>>> without Jailhouse. We now have the local APIC as reliable >>>> high-resolution and high-performance (because it's core-local) >>>> timer. >>> >>> OK, fair. Still wondering what's giving that final bad resolution. The >>> rest of the setup is a Fedora 25 system on QEMU, kernel 4.8, with >>> pristine qemu-vm and linux-x86-demo cells running. >> >> So you are running Jailhouse and the rt-preempt non-root cell on qemu? >> Getting solid rt-performance there might be tricky, that should not be >> your starting point when looking at realtime! > > Yeah, I know QEMU is the place to get RT performance, but I have my > kernel already in place for bare metal testing. Going forward with > those timer resolutions would be a no-go, though, thus why I wanted to > sort that out in the first place. Thanks for the reminder anyway!
If you tested inside QEMU, maybe you didn't provide the guest all CPU features it desired. -cpu kvm64,...+arat? 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.
