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
