From: Peter Zijlstra <peterz@infradead.org>
To: Tejun Heo <tj@kernel.org>
Cc: mingo@elte.hu, efault@gmx.de, avi@redhat.com, paulus@samba.org,
acme@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCHSET] sched,perf: unify tracers in sched and move perf on top of TP
Date: Wed, 05 May 2010 13:38:08 +0200 [thread overview]
Message-ID: <1273059488.1642.245.camel@laptop> (raw)
In-Reply-To: <4BE1406C.2000400@kernel.org>
On Wed, 2010-05-05 at 11:54 +0200, Tejun Heo wrote:
> Hello,
>
> 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?
Because it will bloat the kernel for no reason. And I don't like the
endless indirections either.
Like said, I already really dislike x86 won't even build without
CONFIG_PERF_EVENTS, adding a hard requirement on TRACEEVENTS will only
make the whole thing even worse.
Sure, most distro configs will include both perf and tracepoints, but I
don't want to burden everybody who wants to use perf with the tracepoint
overhead.
As it stands I'd argue to simply drop this whole idea. The SCHED_EVENT()
thing doesn't look like its worth the obfuscation and I'm very much
opposed to making perf and sched_notifiers rely on tracepoints.
I don't see the few direct functions calls we have now as a big problem
and it sure as hell is a lot easier to read than the whole tracepoint
indirection mess.
If you care about the call overhead of the perf hooks, we can do the
same immediate value optimization to them as would be done to the
tracepoints.
next prev parent reply other threads:[~2010-05-05 11:38 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 12:38 [RFC PATCHSET] sched,perf: unify tracers in sched and move perf on top of TP Tejun Heo
2010-05-04 12:38 ` [PATCH 01/12] sched: drop @cpu argument from sched_in preempt notifier Tejun Heo
2010-05-04 17:11 ` Peter Zijlstra
2010-05-04 12:38 ` [PATCH 02/12] sched: rename preempt_notifiers to sched_notifiers and refactor implementation Tejun Heo
2010-05-04 12:38 ` [PATCH 03/12] perf: add perf_event_task_migrate() Tejun Heo
2010-05-05 5:08 ` Frederic Weisbecker
2010-05-05 5:16 ` Tejun Heo
2010-05-05 9:11 ` Peter Zijlstra
2010-05-05 9:37 ` Tejun Heo
2010-05-05 9:50 ` Peter Zijlstra
2010-05-05 9:56 ` Tejun Heo
2010-05-04 12:38 ` [PATCH 04/12] perf: add @rq to perf_event_task_sched_out() Tejun Heo
2010-05-04 17:11 ` Peter Zijlstra
2010-05-04 17:22 ` Tejun Heo
2010-05-04 17:42 ` Peter Zijlstra
2010-05-04 18:22 ` Steven Rostedt
2010-05-04 18:26 ` Peter Zijlstra
2010-05-04 18:32 ` Steven Rostedt
2010-05-05 4:48 ` Tejun Heo
2010-05-05 9:58 ` Tejun Heo
2010-05-07 18:41 ` [tip:sched/core] sched: Remove rq argument to the tracepoints tip-bot for Peter Zijlstra
2010-05-04 12:38 ` [PATCH 05/12] perf: move perf_event_task_sched_in() next to fire_sched_notifiers_in() Tejun Heo
2010-05-04 12:38 ` [PATCH 06/12] sched: relocate fire_sched_notifiers_out() and trace_sched_switch() Tejun Heo
2010-05-04 12:38 ` [PATCH 07/12] sched: coalesce event notifiers Tejun Heo
2010-05-04 12:38 ` [PATCH 08/12] sched: add switch_in and tick tracepoints Tejun Heo
2010-05-04 12:38 ` [PATCH 09/12] perf: factor out perf_event_switch_clones() Tejun Heo
2010-05-04 12:38 ` [PATCH 10/12] perf: make nr_events an int and add perf_online_mutex to protect it Tejun Heo
2010-05-04 12:38 ` [PATCH 11/12] perf: prepare to move sched perf functions on top of tracepoints Tejun Heo
2010-05-04 12:38 ` [PATCH 12/12] perf: " Tejun Heo
2010-05-04 17:29 ` [RFC PATCHSET] sched,perf: unify tracers in sched and move perf on top of TP Peter Zijlstra
2010-05-05 5:00 ` Tejun Heo
2010-05-05 9:06 ` Peter Zijlstra
2010-05-05 9:32 ` Tejun Heo
2010-05-05 9:51 ` Peter Zijlstra
2010-05-05 9:54 ` Tejun Heo
2010-05-05 11:38 ` Peter Zijlstra [this message]
2010-05-05 12:28 ` Tejun Heo
2010-05-05 16:55 ` Ingo Molnar
2010-05-05 18:12 ` Peter Zijlstra
2010-05-05 18:16 ` Peter Zijlstra
2010-05-05 18:30 ` Frederic Weisbecker
2010-05-06 6:28 ` Ingo Molnar
2010-05-06 7:11 ` Tejun Heo
2010-05-06 8:27 ` Ingo Molnar
2010-05-06 8:41 ` Tejun Heo
2010-05-06 8:18 ` Avi Kivity
2010-05-06 6:31 ` Ingo Molnar
2010-05-06 7:04 ` Peter Zijlstra
2010-05-06 7:11 ` Ingo Molnar
2010-05-06 7:29 ` Tejun Heo
2010-05-06 7:33 ` Tejun Heo
2010-05-05 12:33 ` Avi Kivity
2010-05-05 13:09 ` Tejun Heo
2010-05-10 5:20 ` Paul Mackerras
2010-05-10 5:48 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1273059488.1642.245.camel@laptop \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=avi@redhat.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox