• [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercal

    From Paolo Bonzini@21:1/5 to Marcelo Tosatti on Mon Oct 2 14:40:01 2017
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Zijlstra@21:1/5 to Paolo Bonzini on Mon Oct 2 14:50:03 2017
    On Mon, Oct 02, 2017 at 02:30:33PM +0200, Paolo Bonzini wrote:
    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.

    It is indeed not right. Something like:

    raw_spin_lock(&some_lock);

    /* do crud */

    raw_spin_unlock(&some_lock);

    Should not hold off the interrupt that tells you your finger is in
    imminent danger of becoming detached. Only when we do
    local_irq_disable() (ie. raw_spin_lock_irq*() and the like) should we
    avoid interrupt delivery.

    This whole fixation on spinlock regions is misguided and must stop, its
    wrong on all levels.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)