sched_clock: Provide local_clock() and improve documentation
in [Kernel]
|
Prev: sched_clock: Provide local_clock() and improve documentation
Next: [GIT PULL] x86 platform driver updates for 2.6.35
From: Peter Zijlstra on 28 May 2010 14:30 On Fri, 2010-05-28 at 11:11 -0700, Chad Talbott wrote: > On Fri, May 28, 2010 at 6:13 AM, Peter Zijlstra <peterz(a)infradead.org> wrote: > > + * local_clock() -- is cpu_clock() on the current cpu. > > Pretty sure this should read, "is cpu_clock() on *some* cpu," since > there is no guarantee in a preemptible kernel that local_clock() > returns on the same CPU that it was called from. The caller has to do > the preempt protection itself. Current cpu simply has no meaning if preemption isn't disabled. If it is, it has and the result is useful. Some of the local_clock() users are strictly per-cpu (and clearly have preemption disabled), for some there simply is no better clock and simply cope with the small incoherency in time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |