On 05/02/2016 05:25 PM, Radim Krčmář wrote: [...] >> I have some pathological cases where I can easily get all CPUs to poll all >> the time without the shrinking part of the patch. (e.g. guest with 16 CPUs, >> 8 null block devices and 64 dd reading small blocks with O_DIRECT from these disks) >> which cause permanent exits which consumes all 16 host CPUs. Limiting the grow >> did not seem to be enough in my testing, but when I also made shrinking more >> aggressive things improved. > > So the problem is that a large number of VCPUs and devices will often > have a floating irq and the polling always succeeds unless halt_poll_ns > is very small. Poll window doesn't change if the poll succeds, > therefore we need a very agressive shrinker in order to avoid polling? Yes, thats what I concluded after experimenting. > >> But I am certainly open for other ideas how to tune this. > > I don't see good improvements ... the problem seems to lie elsewhere: > Couldn't we exclude floating irqs from kvm_vcpu_check_block()? > > (A VCPU running for other reasons could still handle a floating irq and > we always kick one VCPU, so VM won't starve and other VCPUs won't be > prevented from sleeping.) I thought about that in my first experiments, but we really have to leave vcpu_block for all cases otherwise we might add huge latencies or even starve the delivery. For example the other CPUs can block specific interruption subclass via the control register 6. >>> It would make more sense to me, because we are not interested in latency >>> of invalid wakeups, so they shouldn't affect valid ones. >>> >>>> } else >>>> vcpu->halt_poll_ns = 0; >>>> + vcpu_reset_wakeup(vcpu); >>>> >>>> trace_kvm_vcpu_wakeup(block_ns, waited); >>> >>> (Tracing valid/invalid wakeups could be useful.) >> >> As an extension of the old trace events? > > Yes. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
