Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()

From: David Daney
Date: Tue Oct 27 2015 - 17:45:13 EST


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





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/