Re: [PATCH] bpf: Add bpf_ktime_get_real_ns
From: Daniel Xu <hidden>
Date: 2020-08-18 23:04:23
Also in:
bpf
Hi Maciej, On Tue Aug 18, 2020 at 2:19 PM PDT, Maciej Żenczykowski wrote:
On Tue, Aug 18, 2020 at 2:11 PM Daniel Xu [off-list ref] wrote:quoted
On Mon Jul 27, 2020 at 10:01 PM PDT, Andrii Nakryiko wrote:quoted
On Mon, Jul 27, 2020 at 4:35 PM [off-list ref] wrote:quoted
From: Ashkan Nikravesh <redacted> The existing bpf helper functions to get timestamp return the time elapsed since system boot. This timestamp is not particularly useful where epoch timestamp is required or more than one server is involved and time sync is required. Instead, you want to use CLOCK_REALTIME, which provides epoch timestamp. Hence add bfp_ktime_get_real_ns() based around CLOCK_REALTIME.This doesn't seem like a good idea. With time-since-boot it's very easy to translate timestamp into a real time on the host.For bpftrace, we have a need to get millisecond-level precision on timestamps. bpf has nanosecond level precision via bpf_ktime_get[_boot]_ns(), but to the best of my knowledge userspace doesn't have a high precision boot timestamp. There's /proc/stat's btime, but that's second-level precision. There's also /proc/uptime which has millisecond-level precision but you need to make a second call to get current time. Between those two calls there could be some unknown delta. For millisecond we could probably get away with calculating a delta and warning on large delta but maybe one day we'll want microsecond-level precision. I'll probably put up a patch to add nanoseconds to btime (new field in /proc/stat) to see how it's received. But either this patch or my patch would work for bpftrace. [...] Thanks, DanielNot sure what problem you're trying to solve and thus what exactly you need... but you can probably get something very very close with 1 or 2 of clock_gettime(CLOCK_{BOOTTIME,MONOTONIC,REALTIME}) possibly in a triple vdso call sandwich and iterated a few times and picking the one with smallest delta between 1st and 3rd calls. And then assuming the avg of 1st and 3rd matches the 2nd. ie. 5 times do: t1[i] = clock_gettime(REALTIME) t2[i] = clock_gettime(BOOTTIME) t3[i] = clock_gettime(REALTIME) pick i so t3[i] - t1[i] is smallest t2[i] is near equivalent to (t1[i] + t3[i]) / 2 which basically gives you a REAL to BOOT offset.
I tried out the triple vdso sandwich and I got pretty good results (~30ns ballpark). Thanks for the tip. Daniel