On 2020-05-30 12:30, Mark Kettenis wrote:
Date: Fri, 29 May 2020 17:51:50 +0300
From: Paul Irofti <p...@irofti.net>
On Fri, May 29, 2020 at 03:00:50PM +0200, Mark Kettenis wrote:
Date: Fri, 29 May 2020 13:45:37 +0100
From: Stuart Henderson <s...@spacehopper.org>
On 2020/05/29 13:50, Paul Irofti wrote:
+struct __timekeep {
+ uint32_t major; /* version major number */
+ uint32_t minor; /* version minor number */
+
+ u_int64_t th_scale;
+ unsigned int th_offset_count;
+ struct bintime th_offset;
+ struct bintime th_naptime;
+ struct bintime th_boottime;
+ volatile unsigned int th_generation;
+
+ unsigned int tc_user;
+ unsigned int tc_counter_mask;
+};
Ah good, you got rid of u_int, that was causing problems with port builds.
That in itself is a problem. This means <time.h> is the wrong place
for this struct. We need to find a better place for this.
Since this is now closely linked to the timecounter stuff
<sys/timetc.h> would be an obvious place. Now that file has:
#ifndef _KERNEL
#error "no user-serviceable parts inside"
#endif
you could change that into
#if !defined(_KERNEL) && !defined(_LIBC)
#error "no user-serviceable parts inside"
#endif
and make sure you #define _LIBC brefore uncluding this file where it
is needed. As few places as possible obviously.
Done. Also includes claudio@'s observation.
What are your plans to deal with the potential "skew" between the TSCs
on different processors? We can probably tolerate a small skew
without having to worry about it un userland as long as the skew is
smaller than the time it takes to do a context switch. If you want to
handle the skew in userland, you need to export the skews somewhere on
the timekeep page and we'd need to use rdtscp to read the TSC and
associate it with the right skew.
The results I got from last years work on fixing TSC and adding per CPU
skew, indicated that the skew has small values (two digit numbers
usually). So indeed this does not seem an issue for userland.
Exposing the skews to the user is easy. The hard bit is figuring out on
which CPU you are to pick the proper skew without doing a system call.
If you do a syscall then all of this is for nothing :)
One option is to use a hard-thresholding strategy as you describe.
if (timekeep->maxskew > TK_MAXSKEW_THRESHOLD)
return clock_gettime();
Another is to add support in libc to figure out on what CPU it is
running. I don't have a plan for that yet. You mention associating the
right skew for the RDTSCP call, do you have an example of how to do that?
I will also probably add support for HPET clocks (if this diff goes in)
as some machines do not have a proper, invariant, TSC (like solene@'s)
and, perhaps, others might want to switch for other reasons.
A few more notes below.
I will fix these later and come back with a diff. Thank you for the review!
