Messages in this thread | | | Date | Tue, 27 Oct 2015 14:44:58 -0700 | From | David Daney <> | Subject | Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime() |
| |
On 10/27/2015 02:15 PM, Leonid Yegoshin wrote: > On 10/27/2015 02:02 PM, David Daney wrote: >> On 10/27/2015 01:46 PM, Leonid Yegoshin wrote: >> [...] >>> >>> And finally. clock scaling - what we would do if there are two CPUs with >>> different clock ratios in system? It seems like common kernel timing >>> subsystem can handle that. >>> >> >> The code that executes in userspace must have access to a consistent >> clock source. If you are running on a SMP system that doesn't have >> synchronized CP0.Count registers, then your gettimeofday() cannot use >> CP0.Count (RDHWR $2). > > Right, I agree. > >> >> As far as I know, CP0.Count is the only available counter visible to >> userspace, so you would have to disable the accelerated versions of >> gettimeofday() where you cannot assert that the counters are always >> synchronized. > > Any system with GIC may have access to the same GIC global counter in a > special separate page available for mapping by user in RO mode and it > seems Alex did that. > > Besides that this GIC global counter is used as a major system > clocksource in systems with GIC.
Yes, I had forgotten about the GIC thing.
In any event, there is a set of systems where we could run into problems with unsynchronized clocks. There needs to be an easy way to enable/disable the gettimeofday() acceleration at run time based on the properties of the counter (GIC, CP0.Count, or whatever) chosen at boot time.
For example, On OCTEON single-chip systems we synchronize the the counters and they don't drift. So, we can use CPO.Count. However, on two-chip NUMA configurations there may be clock drift between the two chips, so CPO.Count cannot be used as a clocksource. We have a single kernel image that runs on both types of systems, so we have to be able to enable/disable the gettimeofday() acceleration.
David Daney
> > - Leonid > > > >
| |