On 05/04/2016 10:05 AM, Cornelia Huck wrote:
> On Wed, 4 May 2016 09:50:57 +0200
> Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
>
>> The feedback about the logic triggered some more experiments on my side.
>> So I was experimenting with some different workloads/heuristics and it
>> seems that even more aggressive shrinking (basically resetting to 0 as soon
>> as an invalid poll comes along) does improve the cpu usage even more.
>
> Do we still keep the shrink instead of resetting to 0 explicitly? (In
> case the default shrink factor was set to != 0.) We'd lose a tuneable,
> but it seems the aggressiveness is warranted.
>
>> (So the new diff looks like)
>> @@ -2034,7 +2036,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>> out:
>> block_ns = ktime_to_ns(cur) - ktime_to_ns(start);
>>
>> - if (halt_poll_ns) {
>> + if (!vcpu_valid_wakeup(vcpu))
>> + shrink_halt_poll_ns(vcpu);
>> + else if (halt_poll_ns) {
>> if (block_ns <= vcpu->halt_poll_ns)
>> ;
>
> ...making this
>
> if (halt_poll_ns && vcpu_valid_wakeup(vcpu)) {
>
I decided to keep my version as it should be functionally equivalent for shrink==0
but it allows the performance folks to do future testing for better heuristics.
David, Wanpeng,
I just send out the patch set but I forgot to Cc you :-/
Christian
--
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
