On Tue, 4 Jun 2019, Vincenzo Frascino wrote: > On 31/05/2019 09:46, Arnd Bergmann wrote: > > One open question I touched in my review is whether we want to > > have a vdso version of clock_getres() in all architectures or not. > > I'd prefer to leave it out because there is very little advantage to > > it over the system call (the results don't change at runtime and > > can easily be cached by libc if performance ever matters), and > > it takes up a small amount of memory for the implementation. > > > > I thought about it and I ended up with what proposed in this patchset mainly for > symmetry across all the architectures since in the end they use the same common > code. > > It seems also that there is some performance impact (i.e.): > > clock-getres-monotonic: libc(system call): 296 nsec/call > clock-getres-monotonic: libc(vdso): 5 nsec/call clock_getres() is usually not a hot path operation. > I agree with you though when you say that caching it in the libc is a > possibility to overcome the performance impact. > > > We shouldn't just need it for consistency because all callers > > would require implementing a fallback to the system call > > anyway, to deal with old kernels. libc has the fallback already. Let's aim for 1:1 replacement of the architecture code first and then add the extra bits in separate patches. Thanks, tglx
