Messages in this thread | | | Date | Thu, 6 May 2010 08:28:55 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCHSET] sched,perf: unify tracers in sched and move perf on top of TP |
| |
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Wed, May 05, 2010 at 08:16:36PM +0200, Peter Zijlstra wrote: > > On Wed, 2010-05-05 at 20:15 +0200, Peter Zijlstra wrote: > > > > > > Well, I'd much rather just see a direct call in the code than having to > > > reverse engineer wth hangs onto that _EVENT() junk. > > > > And again, I oppose mandating CONFIG_TRACEEVENT. > > > And me too. But you don't need CONFIG_EVENT_TRACING for that. TRACE_EVENT() > with !CONFIG_EVENT_TRACING only produces tracepoints if CONFIG_TRACEPOINTS. > > In fact, a first progress that would handle these compromizes would be to > have CONFIG_PERF_EVENT_SW. > > For now perf_event_task_sched_in and perf_event_task_sched_out can stay as > is because they are perf core utils. > > But all the rest (faults, migrations, etc..) could be tracepoints builtin > only if CONFIG_PERF_EVENT_SW. Which means CONFIG_PERF_EVENT_SW depends on > CONFIG_TRACEPOINTS. > > But nobody is forced to build CONFIG_PERF_EVENT_SW, breakpoints don't need > it.
Yep. Also, most of the default distro kernels will have 3 sets of facilities:
- preempt notifiers - tracepoints - sw events
which is crazy. We can just standardize on using the tracepoint interface definition methods - they are properly typed, widespread and well-known enough to be perfect for this.
( They are also under intense optimization - the jump-tracepoints patch makes them probably even cheaper than preempt notifiers, in the off case. )
So lets get over this and consolidate our crazy hookery, and stand behind a single facility.
I'm also all for slimming down the trace events facilities by not requiring the /debug/tracing/ bits to be present.
Ingo
| |