[PATCH 07/27] arm64: Substitute gettimeofday with C implementation

On Fri, Nov 9, 2018 at 6:23 PM Mark Salyzyn [off-list ref] wrote:

On 11/09/2018 08:13 AM, Arnd Bergmann wrote:

quoted

quoted

diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index beca249bc2f3..9de0ffc369c5 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S

@@ -88,6 +88,7 @@ VERSION
                 __kernel_gettimeofday;
                 __kernel_clock_gettime;
                 __kernel_clock_getres;
+               __kernel_time;
         local: *;
         };
  }

I would  prefer to not add any deprecated interfaces in the VDSO. If we
have the 64-bit version of clock_gettime, we don't need the 32-bit version
of it, and we don't need gettimeofday() or time() either. The C library
can easily implement those by calling into clock_gettime.

Alas time() calls are simple and in the order of get_res, the cost of
which is a five fold improvement over the alternate higher resolution calls
(clock_gettime or up to 100 fold on some architectures over gettimeofday).

We could measure a small improvement in cpu utilization (and thus
 battery life by extension) attributed to arm64 Android by calling
__kernel_time over __kernel_clock_gettime with coarse resolution.

A game of inches admittedly, but super KISS to add, and it is not as-if
__kernel_time existence will cause an issue with deprecation of a system
call entry point.

But wouldn't it be much better to fix the application in that case?
I can't see any reason why a user would call time() so often that
it shows up in CPU profiles, when the result only changes every
few billion CPU cycles.

Moreover, most architectures cannot return a time64_t from a
system call today, so we'd have to change the system call
entry points on all of those first to implement the slowpath
for a new time64() system call.

      Arnd