From: Sean Christopherson <seanjc@google.com>
To: Colton Lewis <coltonlewis@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, maz@kernel.org,
dmatlack@google.com, bgardon@google.com, oupton@google.com,
ricarkol@google.com
Subject: Re: [PATCH 3/3] KVM: selftests: Print summary stats of memory latency distribution
Date: Wed, 18 Jan 2023 16:43:09 +0000 [thread overview]
Message-ID: <Y8ghnd58W8F8e1GK@google.com> (raw)
In-Reply-To: <20221115173258.2530923-4-coltonlewis@google.com>
On Tue, Nov 15, 2022, Colton Lewis wrote:
> Print summary stats of the memory latency distribution in
> nanoseconds. For every iteration, this prints the minimum, the
> maximum, and the 50th, 90th, and 99th percentiles.
>
> Stats are calculated by sorting the samples taken from all vcpus and
> picking from the index corresponding with each percentile.
>
> The conversion to nanoseconds needs the frequency of the Intel
> timestamp counter, which is estimated by reading the counter before
> and after sleeping for 1 second. This is not a pretty trick, but it
> also exists in vmx_nested_tsc_scaling_test.c
This test shouldn't need to guesstimate the frequency, just use a VM-scoped
KVM_GET_TSC_KHZ, which will provide KVM's default TSC frequency, i.e. the host
frequency. For hardware with a constant TSC, which is everything modern, that
will be as accurate as we can get. For hardware without a constant TSC, well, buy
new hardware :-)
vmx_nested_tsc_scaling_test.c does the weird sleep() behavior because it's trying
to validate that the guest TSC counts at the correct rate, i.e. it is validating
KVM_GET_TSC_KHZ to some extent, and so obviously doesn't fully trust its result.
For tests that just want to measure time, there's no reason not to trust KVM.
next prev parent reply other threads:[~2023-01-18 16:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 17:32 [PATCH 0/3] Calculate memory access latency stats Colton Lewis
2022-11-15 17:32 ` [PATCH 1/3] KVM: selftests: Allocate additional space for latency samples Colton Lewis
2023-01-17 20:32 ` Ricardo Koller
2023-01-18 16:49 ` Sean Christopherson
2023-01-26 18:00 ` Colton Lewis
2022-11-15 17:32 ` [PATCH 2/3] KVM: selftests: Collect memory access " Colton Lewis
2023-01-17 20:43 ` Ricardo Koller
2023-01-18 16:32 ` Sean Christopherson
2023-01-26 18:00 ` Colton Lewis
2023-01-26 19:07 ` Sean Christopherson
2023-01-26 17:58 ` Colton Lewis
2023-01-26 18:30 ` Ricardo Koller
2023-01-17 20:48 ` Ricardo Koller
2023-01-26 17:59 ` Colton Lewis
2022-11-15 17:32 ` [PATCH 3/3] KVM: selftests: Print summary stats of memory latency distribution Colton Lewis
2023-01-17 20:45 ` Ricardo Koller
2023-01-26 17:58 ` Colton Lewis
2023-01-18 16:43 ` Sean Christopherson [this message]
2023-01-26 17:59 ` Colton Lewis
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=Y8ghnd58W8F8e1GK@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=coltonlewis@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=ricarkol@google.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.