On Wed, Dec 23, 2015 at 11:27 AM, Marcelo Tosatti <mtosa...@redhat.com> wrote: > On Mon, Dec 21, 2015 at 02:49:25PM -0800, Andy Lutomirski wrote: >> On Fri, Dec 18, 2015 at 1:49 PM, Marcelo Tosatti <mtosa...@redhat.com> wrote: >> > (busy spin is equally problematic as IPI for realtime guests). >> >> I disagree. It's never been safe to call clock_gettime from an RT >> task and expect a guarantee of real-time performance. We could fix >> that, but it's not even safe on non-KVM. > > The problem is how long the IPI (or busy spinning in case of version > above) interrupts the vcpu.
The busy spin should be a few hundred cycles in the very worst case (a couple of remote cache misses timed such that the guest is spinning the whole time). The IPI is always thousands of cycles no matter what the guest is doing. > >> Sending an IPI *always* stalls the task. Taking a lock (which is >> effectively what this is doing) only stalls the tasks that contend for >> the lock, which, most of the time, means that nothing stalls. >> >> Also, if the host disables preemption or otherwise boosts its priority >> while version is odd, then the actual stall will be very short, in >> contrast to an IPI-induced stall, which will be much, much longer. >> >> --Andy > > 1) The updates are rare. > 2) There are no user complaints about the IPI mechanism. If KVM ever starts directly propagating corrected time (CLOCK_MONOTONIC, for example), then the updates won't be rare. Maybe I'll try to instrument this. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
