On 29/09/2017 22:17, Marcelo Tosatti wrote: > On Fri, Sep 29, 2017 at 07:05:41PM +0200, Paolo Bonzini wrote: >> On 29/09/2017 18:40, Marcelo Tosatti wrote: >>> Thats not the state of things (userspace in vcpu-0 is not specially tailored >>> to not violate latencies in vcpu-1): that is not all user triggered >>> actions can be verified. >>> >>> Think "updatedb", and so on... >> >> _Which_ spinlock is it that can cause unwanted latency while running >> updatedb on VCPU0 and a real-time workload on VCPU1, and only so on virt >> because of the emulator thread? > > Hundreds of them (the one being hit is in timer_interrupt), but i went > to check and there are hundreds of raw spinlocks shared between the > kernel threads that run on isolated CPUs and vcpu-0. > >> Is this still broken if you set up >> priorities for the emulator thread correctly and use PI mutexes in QEMU? > > I don't see why it would not, if you have to schedule the emulator > thread to process and inject I/O interrupts for example. Yes, you're right if it's interrupt injections. If it's unexpected disk accesses, you can just add a QEMU I/O thread on a different physical CPU. The same physical CPU can host I/O threads for different guests if you expect them to do little. I don't understand why is it correct to delay interrupt injection just because VCPU0 is running in a spinlock-protected region? I just cannot see the reason why it's safe and not a recipe for priority inversions. Paolo >> And if so, what is the cause of interruptions in the emulator thread >> and how are these interruptions causing the jitter? > > Interrupt injections. > >> Priorities and priority inheritance (or lack of them) is a _known_ >> issue. Jan was doing his KVM-RT things in 2009 and he was talking about >> priorities[1] back then. The effect of correct priorities is to _lower_ >> jitter, not to make it worse, and anyway certainly not worse than >> SCHED_NORMAL I/O thread. Once that's fixed, we can look at other problems. >> >> Paolo >> >> [1] http://static.lwn.net/images/conf/rtlws11/papers/proc/p18.pdf which >> also mentions pv scheduling
