* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> That's why I'd suggest making _purely_ local time, and then aiming for
> something NTP-like. But maybe there are better solutions out there.
this 'fast local time' was the rough idea we tried to implement via the
cpu_clock(cpu) interface.
cpu_clock() results are loosely coupled to xtime in every scheduler tick
via the scd->tick_gtod logic.
( That way in a sense it tracks NTP time as well, if NTP is fed back
into GTOD, such as when ntpd is running. Granted, this is not the same
quality at all as if it did native NTP-alike corrections, but it at
least has a long-term stability. )
And it only ever does cross-CPU work if we specifically ask for a remote
clock:
if (cpu != raw_smp_processor_id()) {
struct sched_clock_data *my_scd = this_scd();
lock_double_clock(scd, my_scd);
it still does this "serialization looking" even in the local case:
__raw_spin_lock(&scd->lock);
clock = __update_sched_clock(scd, now);
}
__raw_spin_unlock(&scd->lock);
... but that lock is strictly per CPU, so it only matters if there _is_
cross-CPU "interest" in that clock. Otherwise these locks are in essence
just per CPU and cause no cacheline bouncing, etc.
... but we could try to eliminate even that potential for any locking.
On 64-bit it's a real possibility i think. (we need the lock for 32-bit
mainly, the timestamps are all 64 bits)
... it also has all the tsc-stops-in-idle smarts, knows about cpufreq,
etc. Those things are needed even on UP, to not get really bad
transients in time.
That still leaves us with sched_clock() complexity, which has spread out
a bit more than it should have. So it's not all as simple as you'd like
it to be i think, but we are trying hard ...
Ideas to simplify/robustify it are welcome.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
