> The patch in question has no explanation as to why a fully-accurate timestamp
> is required and is likely an oversight.  Using a coarser, but monotically
> increasing, timestamp the overhead can be eliminated.

You are right. I was trying to use ktime_get* functions preferably.
I was aware that current_kernel_time64() could also be used if lesser
granularity was preferred and that it was faster.
I forgot to note that in the commit text.

-Deepa

Reply via email to