Messages in this thread | | | Subject | Re: [PATCH v6 00/19] Unify vDSOs across more architectures | From | Vincenzo Frascino <> | Date | Fri, 14 Jun 2019 13:19:58 +0100 |
| |
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
| |