From: Peter Zijlstra <peterz@infradead.org>
To: Song Liu <song@kernel.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, bpf <bpf@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Nitesh Narayan Lal <nitesh@redhat.com>,
Nicolas Saenz Julienne <nsaenzju@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Xu <peterx@redhat.com>, Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH bpf-next] bpf: introduce helper bpf_raw_read_cpu_clock
Date: Thu, 7 Oct 2021 09:18:56 +0200 [thread overview]
Message-ID: <20211007071856.GM174703@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAPhsuW5Uq78wqK_waeLPpyY6PNgzgtCZkZ4-FFWcF00Pez6cmw@mail.gmail.com>
On Wed, Oct 06, 2021 at 02:37:09PM -0700, Song Liu wrote:
> On Wed, Oct 6, 2021 at 10:52 AM Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >
> >
> >
> > Add bpf_raw_read_cpu_clock helper, to read architecture specific
> > CPU clock. In x86's case, this is the TSC.
> >
> > This is necessary to synchronize bpf traces from host and guest bpf-programs
> > (after subtracting guest tsc-offset from guest timestamps).
>
> Trying to understand the use case. So in a host-guest scenario,
> bpf_ktime_get_ns()
> will return different values in host and guest, but rdtsc() will give
> the same value.
> Is this correct?
No, it will not. Also, please explain if any of this stands a chance of
working for anything other than x86. Or even on x86 in the face of
guest migration.
Also, please explain, again, what's wrong with dumping snapshots of
CLOCK_MONOTONIC{,_RAW} from host and guest and correlating time that
way?
And also explain why BPF needs to do this differently than all the other
tracers.
next prev parent reply other threads:[~2021-10-07 7:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 17:51 [PATCH bpf-next] bpf: introduce helper bpf_raw_read_cpu_clock Marcelo Tosatti
2021-10-06 21:37 ` Song Liu
2021-10-07 7:18 ` Peter Zijlstra [this message]
2021-10-07 9:10 ` Marcelo Tosatti
2021-10-07 17:50 ` [PATCH v2 " Marcelo Tosatti
2021-10-07 18:58 ` Song Liu
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=20211007071856.GM174703@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=nitesh@redhat.com \
--cc=nsaenzju@redhat.com \
--cc=peterx@redhat.com \
--cc=song@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.