On 6/14/19 1:16 PM, Thomas Gleixner wrote: > 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. > Ok, thanks Thomas, I will split the patches accordingly. > Thanks, > > tglx > -- Regards, Vincenzo
