unscaledcycleclock: remove RISC-V support

[aurel32]

Starting with Linux 6.6 [1], RDCYCLE is a privileged instruction on RISC-V and can't be used directly from userland. There is a sysctl option to change that as a transition period, but it will eventually disappear.

The RDTIME instruction is another less accurate alternative, however its frequency varies from board to board, and there is currently now way to get its frequency from userland [2].

Therefore this patch just removes the code for unscaledcycleclock on RISC-V. Without processor specific implementation, abseil relies on std::chrono::steady_clock::now().time_since_epoch() which is basically a wrapper around clock_gettime (CLOCK_MONOTONIC), which in turns use __vdso_clock_gettime(). On RISC-V this VDSO is just a wrapper around RDTIME correctly scaled to use nanoseconds units.

This fixes the testsuite on riscv64, tested on a VisionFive 2 board.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc4c07c89aada16229084eeb93895c95b7eabaa3
[2] #1631

[derekmauro]

We have internal clients that are using this code. It can't simply be removed.

In the other pull request I asked if you could build with -DABSL_USE_UNSCALED_CYCLECLOCK=0. Does that solve your problem?

[derekmauro]

I'm also going to have to track down the callers of this and see what they want to do.

[aurel32]

We have internal clients that are using this code. It can't simply be removed.

Ok. Note that in addition to the 6.6 kernel issue, the use of rdcycle means it can't be use on multicore CPUs, unless pinning the process on a single core, as the controrary to rdtime, the rdcycle counters are not synchronised between cores and just "jumps" if the process is rescheduled on another core.

In the other pull request I asked if you could build with -DABSL_USE_UNSCALED_CYCLECLOCK=0. Does that solve your problem?

I guess you mean at the cmake level. It doesn't work and cmake outputs:

CMake Warning:
  Manually-specified variables were not used by the project:

    ABSL_USE_UNSCALED_CYCLECLOCK

[derekmauro]

I've decided to accept this change and keep the RISC-V code as an internal-only patch. I've also filed an internal bug (b/330872512) for the team that is using it to figure out what they want to do with it. This should be merged soon.

Re: ABSL_USE_UNSCALED_CYCLECLOCK - I was talking about a preprocessor define. There is no corresponding CMake option.

[aurel32]

Thanks a lot @derekmauro

[jrtc27]

RDCYCLE works just fine on FreeBSD; if you want to avoid RDCYCLE, and don't want to use RDTIME, on Linux then at least please instead change the #ifdefs to include non-Linux rather than penalise every OS out there.

[jrtc27]

That or leave it in there and add defined(__riscv) && defined(__linux__) to ABSL_USE_UNSCALED_CYCLECLOCK_DEFAULT, which seems to exist entirely to support this kind of situation?

[aurel32]

RDCYCLE works just fine on FreeBSD; if you want to avoid RDCYCLE, and don't want to use RDTIME, on Linux then at least please instead change the #ifdefs to include non-Linux rather than penalise every OS out there.

Do you mean that RDCYCLE is accessible from userland on FreeBSD? Or do you mean it works on FreeBSD the way it is used in abseil-cpp?

The other reason not to use RDCYCLE is that it is not monotonic if the task is moved between cores, causing the testsuite to fail: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025221

[jrtc27]

It is accessible from userland on FreeBSD. With the caveat of course that you be careful about core migration. For RDTIME there's an (ugly) sysctl available to get the frequency, too. Of course we do have a vDSO implementation of clock_gettime too that uses RDTIME under the hood so it's not awful to lack a faster implementation, I just don't like the idea of deleting code just because it doesn't work on only Linux.