On Friday, June 10, 2016 10:03:14 PM CEST Deepa Dinamani wrote: > On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > In an earlier version, you had a small optimization to > > use ktime_get_real_seconds() instead of current_kernel_time() > > when the granularity is seconds. > > > > Do you still plan to send that one, or did you decide we don't > > need it? > > I was actually planning to use get_seconds() instead of current_kernel_time(). > And, transition both along with vfs to y2038 safe apis. > Difference between ktime_get_real_seconds() and current_kernel_time64() > is not much because they both require sequence counter. > > It didn't make sense to me to optimize current_fs_time() for seconds > only, and not optimize for 1ns granularity also. Ah, you are right: adding another check for second granularity would probably cost more than it would save, since we already don't calculate the exact nanoseconds but just use the timestamp of the last timer tick. > I plan to make changes to the function depending on how we end up > using timespec_trunc() after the addition of range checking. Makes sense. I guess we can skip the range checking for current_fs_time() if we end up not allowing writable mounts on file systems that cannot represent the current time, but we do want the range checking for the other users of timespec_trunc(). Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
