RE: [PATCH] sched: Support current clocksource handling in fallbacksched_clock().
From: Thomas Gleixner
Date: Tue May 26 2009 - 20:05:32 EST
On Tue, 26 May 2009, Mangalampalli, JayantX wrote:
1) please do not top post.
2) please fix your mail client to do proper line breaks at ~78 chars
> Isn't rdtsc inherently dependent on CPU tick rate, which is somewhat
> variable? Shouldn't HPET be more reliable? Or can constant_tsc be
> relied on for important things like scheduler?
1) Please understand that there is an universe which has useful timer
implementations. i.e. almost everything except arch/x86
2) rdtsc is not inherently dependent on CPU frequency. It just depends
on the CPU frequency for most of the CPU implementations which have
the ability to change the CPU core frequency. Newer CPUs have core
frequency invariant TSC implementations, but they are not perfect yet
as the TSC stops in deeper C-states.
3) HPET is reliable but the hardware access to HPET is way more
expensive than the access to TSC. Also it does not scale on SMP
machines as the HPET access is serialized and worse than a global
lock. So there is a damned good reason why we went there to add the
horror of sched_clock.c to utilize TSC for hot code pathes.
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/