[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mu9f97uv.fsf@vitty.brq.redhat.com>
Date: Tue, 18 Feb 2020 17:29:44 +0100
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Wanpeng Li <kernellwp@...il.com>
Cc: Sean Christopherson <sean.j.christopherson@...el.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH v4 1/2] KVM: X86: Less kvmclock sync induced vmexits after VM boots
Paolo Bonzini <pbonzini@...hat.com> writes:
> On 18/02/20 15:54, Vitaly Kuznetsov wrote:
>>> - schedule_delayed_work(&kvm->arch.kvmclock_sync_work,
>>> - KVMCLOCK_SYNC_PERIOD);
>>> + if (vcpu->vcpu_idx == 0)
>>> + schedule_delayed_work(&kvm->arch.kvmclock_sync_work,
>>> + KVMCLOCK_SYNC_PERIOD);
>>> }
>>>
>>> void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>> Forgive me my ignorance, I was under the impression
>> schedule_delayed_work() doesn't do anything if the work is already
>> queued (see queue_delayed_work_on()) and we seem to be scheduling the
>> same work (&kvm->arch.kvmclock_sync_work) which is per-kvm (not
>> per-vcpu).
>
> No, it executes after 5 minutes. I agree that the patch shouldn't be
> really necessary, though you do save on cacheline bouncing due to
> test_and_set_bit.
>
True, but the changelog should probably be updated then.
--
Vitaly
Powered by blists - more mailing lists