From: John Stultz <jstultz@google.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
peterz@infradead.org, mingo@redhat.com,
linux-kernel@vger.kernel.org, sboyd@kernel.org,
eranian@google.com, namhyung@kernel.org, ak@linux.intel.com,
adrian.hunter@intel.com
Subject: Re: [RFC PATCH V2 2/9] perf: Extend ABI to support post-processing monotonic raw conversion
Date: Tue, 14 Feb 2023 12:11:16 -0800 [thread overview]
Message-ID: <CANDhNCoZNmK12beqE5AAnQrpHEW01xKWwOWTQQEsWSuOaH0HRQ@mail.gmail.com> (raw)
In-Reply-To: <0df181b9-fb34-78e8-1376-65d45f7f938f@linux.intel.com>
On Tue, Feb 14, 2023 at 9:00 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
> On 2023-02-14 9:51 a.m., Liang, Kan wrote:
> > If I understand correctly, the idea is to let the user space tool run
> > the above interpoloation algorithm several times to 'guess' the atomic
> > mapping. Using the mapping information to covert the TSC from the PEBS
> > record. Is my understanding correct?
> >
> > If so, to be honest, I doubt we can get the accuracy we want.
> >
>
> I implemented a simple test to evaluate the error.
Very cool!
> I collected TSC -> CLOCK_MONOTONIC_RAW mapping using the above algorithm
> at the start and end of perf cmd.
> MONO_RAW TSC
> start 89553516545645 223619715214239
> end 89562251233830 223641517000376
>
> Here is what I get via mult/shift conversion from this patch.
> MONO_RAW TSC
> PEBS 89555942691466 223625770878571
>
> Then I use the time information from start and end to create a linear
> function and 'guess' the MONO_RAW of PEBS from the TSC. I get
> 89555942692721.
> There is a 1255 ns difference.
> I tried several different PEBS records. The error is ~1000ns.
> I think it should be an observable error.
Interesting. That's a good bit higher than I'd expect as I'd expect a
clock_gettime() call to take ~ double digit nanoseconds range on
average, so the error should be within that.
Can you share your logic?
thanks
-john
next prev parent reply other threads:[~2023-02-14 20:11 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 19:07 [RFC PATCH V2 0/9] Convert TSC to monotonic raw clock for PEBS kan.liang
2023-02-13 19:07 ` [RFC PATCH V2 1/9] timekeeping: Expose the conversion information of monotonic raw kan.liang
2023-02-13 19:28 ` John Stultz
2023-02-13 19:07 ` [RFC PATCH V2 2/9] perf: Extend ABI to support post-processing monotonic raw conversion kan.liang
2023-02-13 19:37 ` John Stultz
2023-02-13 21:40 ` Liang, Kan
2023-02-13 22:22 ` John Stultz
2023-02-14 10:43 ` Peter Zijlstra
2023-02-14 17:46 ` Liang, Kan
2023-02-14 19:37 ` John Stultz
2023-02-14 20:09 ` Liang, Kan
2023-02-14 20:21 ` John Stultz
2023-03-12 20:50 ` Andi Kleen
2023-02-14 19:34 ` John Stultz
2023-02-14 14:51 ` Liang, Kan
2023-02-14 17:00 ` Liang, Kan
2023-02-14 20:11 ` John Stultz [this message]
2023-02-14 20:38 ` Liang, Kan
2023-02-17 23:11 ` John Stultz
2023-03-08 18:44 ` Liang, Kan
2023-03-09 1:17 ` John Stultz
2023-03-09 16:56 ` Liang, Kan
2023-03-11 5:55 ` John Stultz
2023-03-13 21:19 ` Liang, Kan
2023-03-18 6:02 ` John Stultz
2023-03-21 15:26 ` Liang, Kan
2023-02-14 19:52 ` John Stultz
2023-02-13 19:07 ` [RFC PATCH V2 3/9] perf/x86: Factor out x86_pmu_sample_preload() kan.liang
2023-02-13 19:07 ` [RFC PATCH V2 4/9] perf/x86: Enable post-processing monotonic raw conversion kan.liang
2023-02-14 20:02 ` Thomas Gleixner
2023-02-14 20:21 ` Liang, Kan
2023-02-14 20:55 ` Thomas Gleixner
2023-03-21 15:38 ` Liang, Kan
2023-02-13 19:07 ` [RFC PATCH V2 5/9] perf/x86/intel: Enable large PEBS for monotonic raw kan.liang
2023-02-13 19:07 ` [RFC PATCH V2 6/9] tools headers UAPI: Sync linux/perf_event.h with the kernel sources kan.liang
2023-02-13 19:07 ` [RFC PATCH V2 7/9] perf session: Support the monotonic raw clock conversion information kan.liang
2023-02-13 19:07 ` [RFC PATCH V2 8/9] perf evsel, tsc: Support the monotonic raw clock conversion kan.liang
2023-02-13 19:07 ` [RFC PATCH V2 9/9] perf evsel: Enable post-processing monotonic raw conversion by default kan.liang
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=CANDhNCoZNmK12beqE5AAnQrpHEW01xKWwOWTQQEsWSuOaH0HRQ@mail.gmail.com \
--to=jstultz@google.com \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
/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.