On 02/20/2015 04:10 PM, Paolo Bonzini wrote: > On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote: >> On 02/20/2015 03:57 PM, Paolo Bonzini wrote: > >>> Yes, but large latencies just mean the code has to be rewritten (x86 >>> doesn't anymore do event injection in an atomic regions for example). >>> Until it is, using raw_spin_lock is correct. >> >> It does not sound like it. It sounds more like disabling interrupts to >> get things run faster and then limit it on a different corner to not >> blow up everything. > > "This patchset enables running KVM SMP guests with external interrupts > on an underlying RT-enabled Linux. Previous to this patch, a guest with > in-kernel MPIC emulation could easily panic the kernel due to preemption > when delivering IPIs and external interrupts, because of the openpic > spinlock becoming a sleeping mutex on PREEMPT_RT_FULL Linux". > >> Max latencies was decreased "Max latency (us) 70 62" and that >> is why this is done? For 8 us and possible DoS in case there are too >> many cpus? > > My understanding is that: > > 1) netperf can get you a BUG KVM, and raw_spinlock fixes that May I please see a backtrace with context tracking which states where the interrupts / preemption gets disabled and where the lock was taken? I'm not totally against this patch I just want to make sure this is not a blind raw conversation to shup up the warning the kernel throws. > 2) cyclictest did not trigger the BUG, and you can also get reduced > latency from using raw_spinlock. > > I think we agree that (2) is not a factor in accepting the patch. good :) > > Paolo > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
