On Tue, 11 Nov 2008, Peter Zijlstra wrote: > On Tue, 2008-11-11 at 22:31 +0000, David Howells wrote: > > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx> wrote: > > > > > @@ -52,18 +57,22 @@ unsigned long long sched_clock(void) > > > ... > > > + preempt_disable_notrace(); > > > > Please, no! sched_clock() is called with preemption or interrupts disabled > > everywhere except from some debugging code (lock tracing IIRC). If you need > > to insert this preemption disablement somewhere, please insert it there. At > > least then sched_clock() will be called consistently. > > Agreed. You could do a WARN_ON(!in_atomic); in sched_clock() depending > on DEBUG_PREEMPT or something to ensure this. It would also be nice if this requirement (calling sched_clock with preemption disabled) was documented somewhere more obvious. Doing as Peter suggested, adding a WARN_ON and documenting that this must be called with preemption disabled, would be nice. -- Steve -- 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
