[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANRm+CwCreBC_EErbTa98dvtNzj5tzHDm1=zNozAGkVLoEXSUQ@mail.gmail.com>
Date: Mon, 3 Jul 2017 16:08:25 +0800
From: Wanpeng Li <kernellwp@...il.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kvm <kvm@...r.kernel.org>, Radim Krcmar <rkrcmar@...hat.com>,
Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH 3/3] KVM: LAPIC: Fix lapic timer injection delay
2017-07-03 15:30 GMT+08:00 Paolo Bonzini <pbonzini@...hat.com>:
>
>
> On 02/07/2017 03:56, Wanpeng Li wrote:
>>>> - if (!apic_lvtt_period(apic) && atomic_read(&ktimer->pending))
>>>> + if (!apic_lvtt_period(apic) && (r || atomic_read(&ktimer->pending))) {
>>>> + if (r)
>>>> + apic_timer_expired(apic);
>>>> return false;
>>>> + }
>>>
>>> This logic is not the same as in my v4
>>> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1434040.html
>>> . You return false for the expired timer and actually it will switch
>>> to sw timer.
>>
>> Ah, I miss read it, the rebase is correct.
>
> Yeah, I'm not entirely satisfied with it but it's working: start_sw
> timer will see ktimer->pending and do nothing.
>
> But thinking more about it, maybe the "if (r)" can be omitted
> completely? We need to benchmark it but it can be done.
"if (r)" makes codes more understandable, in addition, calling expired
the pending timer here looks weird though ktimer->pending.
Regards,
Wanpeng Li
Powered by blists - more mailing lists