On Thu, Oct 13, 2022 at 7:39 PM John Stultz <jstultz@xxxxxxxxxx> wrote: > > On Mon, Sep 26, 2022 at 2:18 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > I have a question about ktime_get_mono_fast_ns(), which is used by the > > BPF helper bpf_ktime_get_ns() among other use cases. The comment above > > this function specifies that there are cases where the observed clock > > would not be monotonic. > > > > I had 2 beginner questions: > > Thinking about this a bit more, I have my own "beginner question": Why > does bpf_ktime_get_ns() need to use the ktime_get_mono_fast_ns() > accessor instead of ktime_get_ns()? > > I don't know enough about the contexts that bpf logic can run, so it's > not clear to me and it's not obviously commented either. I am not the best person to answer this question (the BPF list is CC'd, it's full of more knowledgeable people). My understanding is that because BPF programs can basically be run in any context (because they can attach to almost all functions / tracepoints in the kernel), the time accessor needs to be safe in all contexts. Now that I know that ktime_get_mono_fast_ns() can drift significantly, I am wondering why we don't just read sched_clock(). Can the difference between sched_clock() on different cpus be even higher than the potential drift from ktime_get_mono_fast_ns()? > > Looking at some of the uses of ktime_get_mono_fast_ns() spread around > the kernel, some are clearly necessary (trying to get timestamps in > suspend paths after timekeeping might be shutdown, etc). But there's > also a few cases where the need isn't clear and I'm worried the > reasoning is because it says "fast" in its name. > "Why stop with ktime_get_mono_fast_ns() when you could instead use > ktime_get_real_fast()! It's *real fast*!" :) > > thanks > -john
