[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211007071856.GM174703@worktop.programming.kicks-ass.net>
Date: Thu, 7 Oct 2021 09:18:56 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Song Liu <song@...nel.org>
Cc: Marcelo Tosatti <mtosatti@...hat.com>, bpf <bpf@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
Nitesh Narayan Lal <nitesh@...hat.com>,
Nicolas Saenz Julienne <nsaenzju@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Xu <peterx@...hat.com>,
Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCH bpf-next] bpf: introduce helper bpf_raw_read_cpu_clock
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@...hat.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.
Powered by blists - more mailing lists