* Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote: > Hi, > > This is my current proposal to replace the rq->clock stuff (and > possibly cpu_clock()). > > it _DOESN'T_ boot ;-/ and I seem to have caught a flu that makes my > whole body hurt like hell, so I'm not getting anything done. ouch - getter better soon! > Brain dump before I crash: > > - architectures that have a 'perfect' hardware clock can set > CONFIG_HAVE_STABLE_CLOCK ok. > - the 'jiffie' window might be superfulous when we update tick_gtod > before the __update_sched_clock() call in sched_clock_tick() > > - cpu_clock() might be implemented as: > > sched_clock_cpu(smp_processor_id()) > > if the accuracy proves good enough - how far can TSC drift in a > single jiffie when considering the filtering and idle hooks? it 'can' be very bad - so we have to assume it's random and fall back to jiffies quality in that case. In practice on most x86 CPUs it wont drift that far - even drifting TSCs drift minimally (there are AMD Athlon64/Opteron CPUs where a CPU in HLT will cause the clock and the TSC to drift a bit) - and stopping TSCs will just stop. But in terms of BIOSes trying to fix things up and in terms of cpufreq artifacts (the CPU's clock itself going through transients) anything can happen and the code must be robust. > - what other architectures besides x86 would need this? we rarely get any interactivity reports from anything non-x86 so i doubt it truly matters on anything but x86. If it _breaks_ in terms of crashing or locking we do hear from other architectures ;-) 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
