* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Thu, 2009-11-26 at 11:32 +0100, Peter Zijlstra wrote: > > On Thu, 2009-11-26 at 11:29 +0100, Ingo Molnar wrote: > > > * Tejun Heo <tj@xxxxxxxxxx> wrote: > > > > > > > Rename preempt_notifier to sched_notifier, move it from preempt.h to > > > > sched.h, drop sched_ prefixes from ops names and make sched_notifier > > > > always enabled. > > > > > > > > This is to prepare for adding more notification hooks. This patch > > > > doesn't make any functional changes. > > > > > > The sched notifiers and the various event notifiers we have in the same > > > codepaths should really be unified into a single callback framework. > > > > > > We have these _5_ callbacks: > > > > > > .... > > > perf_event_task_sched_out(prev, next, cpu); > > > .... > > > fire_sched_out_notifiers(prev, next); > > > .... > > > trace_sched_switch(rq, prev, next); > > > .... > > > perf_event_task_sched_in(current, cpu_of(rq)); > > > fire_sched_in_notifiers(current); > > > .... > > > > > > That could be done with just two callbacks - one for sched-out, one for > > > sched-in. > > > > > > The best way to do that would be to use two TRACE_EVENT() callbacks, > > > make them unconditional and register to them. (with wrappers to make it > > > all convenient to use) > > > > > > This requires some work but needs to be done. > > > > Ugh,.. it also makes TRACE_EVENT unconditional. > > > > That really wants a separate option.. What we could do is take regular > > notifier lists and extend them to auto-generate a tracepoint when the > > trace stuff is enabled or something. I wouldnt mind some form of TRACE_EVENT_CALLBACK() thing whose callback facility is always available, even if CONFIG_PERF_EVENTS and CONFIG_TRACING is disabled. It might grow out of notifier.h - albeit i suspect the shorter path would be to grow it from TRACE_EVENT(). ( The various pagefault notifiers in arch/x86/mm/fault.c could use this facility too. ) What we definitely dont want is the proliferation of callbacks. > Also, there is this thing about direct and indirect function calls. Yeah. The norm would be for those points to be disabled and have near zero overhead. If it has callbacks registered it should be light-weight. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
