From: Like Xu <like.xu@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, rkrcmar@redhat.com,
sean.j.christopherson@intel.com, vkuznets@redhat.com,
Jim Mattson <jmattson@google.com>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
ak@linux.intel.com, wei.w.wang@intel.com, kan.liang@intel.com,
like.xu@intel.com, ehankland@google.com, arbel.moshe@oracle.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] KVM: x86/vPMU: Reuse perf_event to avoid unnecessary pmc_reprogram_counter
Date: Tue, 1 Oct 2019 20:18:45 +0800 [thread overview]
Message-ID: <e6beb99d-3073-b03a-3e30-449fc79cd203@linux.intel.com> (raw)
In-Reply-To: <20191001082218.GK4519@hirez.programming.kicks-ass.net>
Hi Peter,
On 2019/10/1 16:22, Peter Zijlstra wrote:
> On Mon, Sep 30, 2019 at 03:22:56PM +0800, Like Xu wrote:
>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>> index 46875bbd0419..74bc5c42b8b5 100644
>> --- a/arch/x86/kvm/pmu.c
>> +++ b/arch/x86/kvm/pmu.c
>> @@ -140,6 +140,35 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 type,
>> clear_bit(pmc->idx, (unsigned long*)&pmc_to_pmu(pmc)->reprogram_pmi);
>> }
>>
>> +static void pmc_pause_counter(struct kvm_pmc *pmc)
>> +{
>> + if (!pmc->perf_event)
>> + return;
>> +
>> + pmc->counter = pmc_read_counter(pmc);
>> +
>> + perf_event_disable(pmc->perf_event);
>> +
>> + /* reset count to avoid redundant accumulation */
>> + local64_set(&pmc->perf_event->count, 0);
>
> Yuck, don't frob in data structures you don't own.
Yes, it's reasonable. Thanks.
>
> Just like you exported the IOC_PERIOD thing, so too is there a
> IOC_RESET.
>
> Furthermore; wth do you call pmc_read_counter() _before_ doing
> perf_event_disable() ? Doing it the other way around is much cheaper,
> even better, you can use perf_event_count() after disable.
Yes, it's much better and let me apply this.
>
>> +}
>> +
>> +static bool pmc_resume_counter(struct kvm_pmc *pmc)
>> +{
>> + if (!pmc->perf_event)
>> + return false;
>> +
>> + /* recalibrate sample period and check if it's accepted by perf core */
>> + if (perf_event_period(pmc->perf_event,
>> + (-pmc->counter) & pmc_bitmask(pmc)))
>> + return false;
>
> I'd do the reset here, but then you have 3 function in a row that do
> perf_event_ctx_lock()+perf_event_ctx_unlock(), which is rather
> expensive.
Calling pmc_pause_counter() is not always followed by calling
pmc_resume_counter(). The former may be called multiple times before the
later is called, so if we do not reset event->count in the
pmc_pause_counter(), it will be repeatedly accumulated into pmc->counter
which is a functional error.
>
>> +
>> + /* reuse perf_event to serve as pmc_reprogram_counter() does*/
>> + perf_event_enable(pmc->perf_event);
>> + clear_bit(pmc->idx, (unsigned long *)&pmc_to_pmu(pmc)->reprogram_pmi);
>> + return true;
>> +}
>
next prev parent reply other threads:[~2019-10-01 12:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 7:22 [PATCH 0/3] KVM: x86/vPMU: Efficiency optimization by reusing last created perf_event Like Xu
2019-09-30 7:22 ` [PATCH 1/3] perf/core: Provide a kernel-internal interface to recalibrate event period Like Xu
2019-10-01 2:27 ` kbuild test robot
2019-10-01 2:27 ` kbuild test robot
2019-10-01 2:46 ` kbuild test robot
2019-10-01 2:46 ` kbuild test robot
2019-10-07 12:01 ` Paolo Bonzini
2019-10-07 13:25 ` Liang, Kan
2019-10-07 15:05 ` Paolo Bonzini
2019-09-30 7:22 ` [PATCH 2/3] KVM: x86/vPMU: Reuse perf_event to avoid unnecessary pmc_reprogram_counter Like Xu
2019-10-01 8:22 ` Peter Zijlstra
2019-10-01 12:18 ` Like Xu [this message]
2019-09-30 7:22 ` [PATCH 3/3] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC Like Xu
2019-10-01 8:23 ` Peter Zijlstra
2019-10-01 12:33 ` Like Xu
2019-10-08 12:11 ` Peter Zijlstra
2019-10-09 3:14 ` Like Xu
2019-10-09 7:15 ` Paolo Bonzini
2019-10-09 8:07 ` Like Xu
2019-10-09 8:16 ` Peter Zijlstra
2019-10-09 9:21 ` Paolo Bonzini
2019-10-09 9:32 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6beb99d-3073-b03a-3e30-449fc79cd203@linux.intel.com \
--to=like.xu@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=arbel.moshe@oracle.com \
--cc=ehankland@google.com \
--cc=jmattson@google.com \
--cc=kan.liang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=wei.w.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.