> Turn on CONFIG_HAVE_UNSTABLE_SCHED_CLOCK for SGI_SN. > > SGI Altix has unsynchronized itc clocks. This results in rq->clock > occasionally being set to a time in the past by a remote cpu. SGI Altix is definitely the worst offender here. On heterogeneneous systems with different model cpus across nodes the itc rate may differ by hundreds of megahertz. Even when all cpus are at the same rated speed, different nodes are driven from different crystals, so the itc values will slowly drift apart (Linux discovers this from SAL and so doesn't bother to synchronize them). > Note that it is possible that this problem may exist for other ia64 > machines as well, based on the following comment for sched_clock() in > arch/ia64/kernel/head.S: > > * Return a CPU-local timestamp in nano-seconds. This timestamp is > * NOT synchronized across CPUs its return value must never be > * compared against the values returned on another CPU. The usage in > * kernel/sched.c ensures that. When sched_clock() was first created this was part of its definition. It meant that sched_clock could be simple & fast because it didn't need to be synchronized across cpus. It seems that new uses have grown for it that no longer allow that flexibility. All ia64 systems are potentially affected ... but perhaps you might never see the problem on most because the itc clocks are synced as close as s/w can get them when cpus are brought on line. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |