* Jan Kiszka <[email protected]> [2017-06-26 18:42:13 +0200]: > 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
*is not* (damn) > > 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? Never seem this arat before, thanks! Will test now (with and without the patch). > > 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. -- Gustavo Lima Chaves Intel - Open Source Technology Center -- 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.
