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.
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
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 62:31:54 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,568 |