[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091126115605.GA15189@elte.hu>
Date: Thu, 26 Nov 2009 12:56:05 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Frédéric Weisbecker
<fweisbec@...il.com>
Cc: Tejun Heo <tj@...nel.org>, Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Mike Galbraith <efault@....de>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/4 tip/sched/core] sched: rename preempt_notifier to
sched_notifier and always enable it
* Peter Zijlstra <peterz@...radead.org> 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@...nel.org> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists