* 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! > > Henning > > > > > > > And as reference clock, the PM timer is easily and cleanly exported > > > to inmates - that's why we do that. > > > > OK, I'll keep searching the source of that strange behavior, thanks. > > > > > > > > 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.
