> 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