Re: [PATCH/RFC] KVM: halt_polling: provide a way to qualify wakeups during poll

[Christian Borntraeger <borntraeger@de.ibm.com>]

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.
>