On 29/09/2017 18:40, Marcelo Tosatti wrote: >> If you know you have this kind disk workload, you must use virtio-blk or >> virtio-scsi with iothreads and place the iothreads on their own physical >> CPUs. >> >> Among "run arbitrary workloads", "run real-time workloads", "pack stuff >> into as few physical CPUs as possible", you can only pick two. > > 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? Is this still broken if you set up priorities for the emulator thread correctly and use PI mutexes in QEMU? And if so, what is the cause of interruptions in the emulator thread and how are these interruptions causing the jitter? 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
