lkml.org 
[lkml]   [2016]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
Date
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@arndb.de> 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

\
 
 \ /
  Last update: 2016-06-11 23:21    [W:0.059 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site