From: Sean Christopherson <seanjc@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Colton Lewis <coltonlewis@google.com>,
pbonzini@redhat.com, shuah@kernel.org, dmatlack@google.com,
vipinsh@google.com, andrew.jones@linux.dev, bgardon@google.com,
ricarkol@google.com, oliver.upton@linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: selftests: Provide generic way to read system counter
Date: Tue, 28 Mar 2023 08:38:37 -0700 [thread overview]
Message-ID: <ZCMJ/Vs3t63rU9z3@google.com> (raw)
In-Reply-To: <86r0t9w5jp.wl-maz@kernel.org>
On Tue, Mar 28, 2023, Marc Zyngier wrote:
> On Tue, 21 Mar 2023 19:10:04 +0000,
> Colton Lewis <coltonlewis@google.com> wrote:
> > In context, I'm trying to measure the time it takes to write to a buffer
> > *with dirty memory logging enabled*. What do you mean by zero? I can
> > confirm from running this code I am not measuring zero time.
>
> See my earlier point: the counter tick is a few MHz, and the CPU
> multiple GHz.
On x86, the system counter (TSC) counts at multiple GHz, so we should be able to
continue with that approach for x86.
> So unless "whatever" is something that takes a significant time (several
> thousands of CPU cycles), you'll measure nothing using the counter. Page
> faults will probably show, but not a normal access.
>
> The right tool for this job is to use PMU events, as they count at the CPU
> frequency.
Out of curiosity, what does the kernel end up using for things like ndelay()? I
tried to follow the breadcrumbs for ARM and got as far as arm_arch_timer.c, but
after that I'm more than a bit lost.
next prev parent reply other threads:[~2023-03-28 15:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 22:27 [PATCH v2 0/2] Calculate memory access latency stats Colton Lewis
2023-03-16 22:27 ` [PATCH v2 1/2] KVM: selftests: Provide generic way to read system counter Colton Lewis
2023-03-17 9:26 ` Andrew Jones
2023-03-21 19:08 ` Colton Lewis
2023-03-17 17:04 ` Vipin Sharma
2023-03-21 19:09 ` Colton Lewis
2023-03-17 17:09 ` Marc Zyngier
2023-03-21 19:10 ` Colton Lewis
2023-03-28 10:09 ` Marc Zyngier
2023-03-28 15:38 ` Sean Christopherson [this message]
2023-03-28 15:50 ` Marc Zyngier
2023-03-28 21:51 ` Colton Lewis
2023-03-16 22:27 ` [PATCH v2 2/2] KVM: selftests: Print summary stats of memory latency distribution Colton Lewis
2023-03-17 18:16 ` Vipin Sharma
2023-03-21 19:10 ` Colton Lewis
2023-03-21 21:21 ` Sean Christopherson
2023-03-24 16:26 ` Colton Lewis
-- strict thread matches above, loose matches on Subject: below --
2023-03-19 5:42 [PATCH v2 1/2] KVM: selftests: Provide generic way to read system counter kernel test robot
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=ZCMJ/Vs3t63rU9z3@google.com \
--to=seanjc@google.com \
--cc=andrew.jones@linux.dev \
--cc=bgardon@google.com \
--cc=coltonlewis@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=ricarkol@google.com \
--cc=shuah@kernel.org \
--cc=vipinsh@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.