From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28951C76195 for ; Fri, 17 Mar 2023 17:11:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230252AbjCQRKa (ORCPT ); Fri, 17 Mar 2023 13:10:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230313AbjCQRKK (ORCPT ); Fri, 17 Mar 2023 13:10:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A196497D4 for ; Fri, 17 Mar 2023 10:09:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BE118B82653 for ; Fri, 17 Mar 2023 17:09:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E1FCC433EF; Fri, 17 Mar 2023 17:09:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679072982; bh=4CTH4rBxEXVY5v/WEtmokaUGJ626djZ1Fv+YitxfAlI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QLIEMMh7gOR0ExBHs0bxvkmcS9oD0FOzoY6rtvivXvR6hUugWa9lZ9qTLL8/TLSnK mTFoMtSoX8SnAV9F+0rSJavQbRYquiEN181F9Pg0WjU4+e+V/GGRmzlcXMCvtvyQOe UB+G73FOIjnuNCvmCr2HPf+G3IjxhIby87TYt5HegFV99Kl+mFnWiCQOayaBLKiwD/ ooxVKCL+7L38hPkxHd2AQOVI3FPtxhDyZnhE8gOrQbOBlETWNWmQXoXYBGBbHn1s9s ZvUTvmLvbwFYEQtNB0AiPGMwBL1h5Dh/IGE9IJP0iUJ9JsK+8b1RHewj5BndG1bb/L NwjiFGjtk/Seg== Received: from [89.213.33.168] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pdDaG-0010UA-1Y; Fri, 17 Mar 2023 17:09:40 +0000 Date: Fri, 17 Mar 2023 17:09:39 +0000 Message-ID: <87y1nvgv8s.wl-maz@kernel.org> From: Marc Zyngier To: Colton Lewis Cc: Paolo Bonzini , Shuah Khan , Sean Christopherson , David Matlack , Vipin Sharma , Andrew Jones , Ben Gardon , Ricardo Koller , Oliver Upton , kvm@vger.kernel.org Subject: Re: [PATCH v2 1/2] KVM: selftests: Provide generic way to read system counter In-Reply-To: <20230316222752.1911001-2-coltonlewis@google.com> References: <20230316222752.1911001-1-coltonlewis@google.com> <20230316222752.1911001-2-coltonlewis@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 89.213.33.168 X-SA-Exim-Rcpt-To: coltonlewis@google.com, pbonzini@redhat.com, shuah@kernel.org, seanjc@google.com, dmatlack@google.com, vipinsh@google.com, andrew.jones@linux.dev, bgardon@google.com, ricarkol@google.com, oliver.upton@linux.dev, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 16 Mar 2023 22:27:51 +0000, Colton Lewis wrote: > > Provide a generic function to read the system counter from the guest > for timing purposes. A common and important way to measure guest > performance is to measure the amount of time different actions take in > the guest. Provide also a mathematical conversion from cycles to > nanoseconds and a macro for timing individual statements. > > Substitute the previous custom implementation of a similar function in > system_counter_offset_test with this new implementation. > > Signed-off-by: Colton Lewis > --- > .../testing/selftests/kvm/include/kvm_util.h | 15 ++++++++++ > tools/testing/selftests/kvm/lib/kvm_util.c | 30 +++++++++++++++++++ > .../kvm/system_counter_offset_test.c | 10 ++----- > 3 files changed, 47 insertions(+), 8 deletions(-) > > diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h > index c9286811a4cb..8b478eabee4c 100644 > --- a/tools/testing/selftests/kvm/include/kvm_util.h > +++ b/tools/testing/selftests/kvm/include/kvm_util.h > @@ -10,4 +10,19 @@ > #include "kvm_util_base.h" > #include "ucall_common.h" > > +#if defined(__aarch64__) || defined(__x86_64__) > + > +uint64_t cycles_read(void); > +double cycles_to_ns(struct kvm_vcpu *vcpu, double cycles); > + > +#define MEASURE_CYCLES(x) \ > + ({ \ > + uint64_t start; \ > + start = cycles_read(); \ > + x; \ You insert memory accesses inside a sequence that has no dependency with it. On a weakly ordered memory system, there is absolutely no reason why the memory access shouldn't be moved around. What do you exactly measure in that case? > + cycles_read() - start; \ I also question the usefulness of this exercise. You're comparing the time it takes for a multi-GHz system to put a write in a store buffer (assuming it didn't miss in the TLBs) vs a counter that gets updated at a frequency of a few tens of MHz. My guts feeling is that this results in a big fat zero most of the time, but I'm happy to be explained otherwise. > + }) > + > +#endif > + > #endif /* SELFTEST_KVM_UTIL_H */ > diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c > index 3ea24a5f4c43..780481a92efe 100644 > --- a/tools/testing/selftests/kvm/lib/kvm_util.c > +++ b/tools/testing/selftests/kvm/lib/kvm_util.c > @@ -2135,3 +2135,34 @@ void __attribute((constructor)) kvm_selftest_init(void) > > kvm_selftest_arch_init(); > } > + > +#if defined(__aarch64__) > + > +#include "arch_timer.h" > + > +uint64_t cycles_read(void) > +{ > + return timer_get_cntct(VIRTUAL); > +} > + > +double cycles_to_ns(struct kvm_vcpu *vcpu, double cycles) > +{ > + return cycles * (1e9 / timer_get_cntfrq()); We already have all the required code to deal with ns conversions using a multiplier and a shift, avoiding floating point like the plague it is. Please reuse the kernel code for this, as you're quite likely to only measure the time it takes for KVM to trap the FP registers and perform a FP/SIMD switch... M. -- Without deviation from the norm, progress is not possible.