From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Zhang Subject: Re: [PATCH] kvm: x86: make lapic hrtimer pinned Date: Thu, 7 Apr 2016 10:08:00 +0800 Message-ID: <5705C100.7000001@gmail.com> References: <20160404164607.09e306fa@redhat.com> <1459803623.6219.28.camel@redhat.com> <57035899.6080609@gmail.com> <20160405155438.GD21537@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Rik van Riel , Luiz Capitulino , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, mtosatti@redhat.com, bsd@redhat.com To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mail-pa0-f66.google.com ([209.85.220.66]:33581 "EHLO mail-pa0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751649AbcDGCIG (ORCPT ); Wed, 6 Apr 2016 22:08:06 -0400 In-Reply-To: <20160405155438.GD21537@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2016/4/5 23:54, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2016-04-05 14:18+0800, Yang Zhang: >> On 2016/4/5 5:00, Rik van Riel wrote: >>> Given that delivering a timer to a guest seems to >>> involve trapping from the guest to the host, anyway, >>> I don't see a downside to your patch. >>> >>> If that is ever changed (eg. allowing delivery of >>> a timer interrupt to a VCPU without trapping to the >>> host), we may want to revisit this. >> >> Posted interrupt helps in this case. Currently, KVM doesn't use PI f= or lapic >> timer is due to same affinity for lapic timer and VCPU. Now, we can = change >> to use PI for lapic timer. The only concern is what's frequency of t= imer >> migration in upstream Linux? If it is frequently, will it bring addi= tional >> cost? > > It's a scheduler bug if the timer migration frequency would matter. := ) > Additional costs arise when the timer and VCPU are on two different > CPUs. (e.g. if both CPUs are in deep C-state, we wasted one wakeup; > the timer would sometimes needs to send an interrupt.) Yes, it's possible. But the premise is VCPU is pinned to other CPU.=20 Normally, the VCPU will wake up on the same CPU where timer interrupt i= s=20 stay if CPU is idle. > > Fine tuned KVM could benefit from having the lapic timer backend on a > different physical core, but the general case would need some experie= nce > to decide. > > I think that we'd still want to have timer interrupts on the same > physical core if the host didn't have PI, and the fraction of timers > that can be injected without a guest entry is important to decide > whether PI can make the effort worthwhile. Agree. I can do some experiences to see how much improvement we can get= =2E > > The biggest benefit might come from handling multiple lapic timers in > one host interrupt. This is should be another story.We need to align multiple lapic timers=20 into one timer firstly.:) --=20 best regards yang