sched,perf: unify tracers in sched and move perf on top of TP
in [Kernel]
|
Prev: sched: drop @cpu argument from sched_in preempt notifier
Next: [PATCH][GIT PULL] ring-buffer: Wrap open-coded WARN_ONCE
From: Peter Zijlstra on 6 May 2010 03:10 On Thu, 2010-05-06 at 08:31 +0200, Ingo Molnar wrote: > * Peter Zijlstra <peterz(a)infradead.org> 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. > > Direct calls into code were fine 10 years ago, but since then we got: > > - preempt notifiers Are per task an no good for driving perf. > - sw events > - tracepoints Are unrelated to the core perf scheduler calls. > Which add up to a lot more than just a plain call into code. > > Also, with the jump-optimizations we will have tracepoints that are _cheaper_ > than a plain function call. Which can just as easily be used on the core perf hooks. > > Also, we don't need ABI muck for this. > > we already have an ABIs in place here - this would just properly unify and > enumerate it. I'm not getting it, this is about in-kernel stuff, there are _NO_ in kernel ABIs. -- 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/
From: Paul Mackerras on 10 May 2010 01:30
On Wed, May 05, 2010 at 11:54:52AM +0200, Tejun Heo wrote: > On 05/05/2010 11:51 AM, Peter Zijlstra wrote: > >> I was wondering the other way around - ie. the possibility to make > >> perf optional and maybe even as a module which depends on TPs, which > >> would be nicer than the current situation and make the code less > >> cluttered too. > > > > I really really hate making perf rely on tracepoints. > > Hmmm.... may I ask why? Unifying hooking mechanism seems like a good > idea to me and it's not like it's gonna add any runtime overhead > although it does complicate init/exit but well that's something you > have to pay if you wanna do things dynamically and sans the ifdef > stuff it's like a couple hundred lines of isolated code. Don't forget where perf_events started out - as a way to count and record hardware events. So perf_events is very useful even in a kernel that has no tracing infrastructure configured in at all. Paul. -- 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/ |