On Wed, 22 Feb 2017, Jason Vas Dias wrote: > Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is > read or written . It is probably because it genuinuely does not support > any cpuid > 13 , or the modern TSC_ADJUST interface. Err no. TSC_ADJUST is available when CPUID(70 EBX has bit 1 set. Please provide the output of: # cpuid -1 -r for that machine > This is probably why my clock_gettime() latencies are so bad. Now I have > to develop a patch to disable all access to TSC_ADJUST MSR if > boot_cpu_data.cpuid_level <= 13 . I really have an unlucky CPU :-) . Can you just try to boot linux 4.10 on that machine an report whether it works? It will touch the TSC_ADJUST MRS when the feature bit is set. > But really, I think this issue goes deeper into the fundamental limits of > time measurement on Linux : it is never going to be possible to measure > minimum times with clock_gettime() comparable with those returned by > rdtscp instruction - the time taken to enter the kernel through the VDSO, > queue an access to vsyscall_gtod_data via a workqueue, access it & do > computations & copy value to user-space Sorry, that's not how the VDSO works. It does not involve workqueues, copy to user space and whatever. VDSO is mapped into user space and only goes into the when TSC is not working or the VDSO access is disabled or you want to access a CLOCKID which is not supported in the VDSO. > is NEVER going to be up to the job of measuring small real-time durations > of the order of 10-20 TSC ticks . clock_gettime(CLOCK_MONOTONIC) via VDSO takes ~20ns on my haswell laptop > I think the best way to solve this problem going forward would be to store > the entire vsyscall_gtod_data data structure representing the current > clocksource > in a shared page which is memory-mappable (read-only) by user-space . This is what VDSO does. It provides the data R/O to user space and it also provides the accessor functions. CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_COARSE and CLOCK_REALTIME_COARSE are handled in the VDSO (user space) and never enter the kernel. I really have a hard time to understand what you are trying to solve. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
