This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemtap broken by removal of register_timer_hook
- From: Frederic Weisbecker <fweisbec at gmail dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Mel Gorman <mgorman at suse dot de>, Ingo Molnar <mingo at kernel dot org>, LKML <linux-kernel at vger dot kernel dot org>, SystemTap <systemtap at sourceware dot org>, Thomas Gleixner <tglx at linutronix dot de>
- Date: Tue, 30 Apr 2013 02:19:00 +0200
- Subject: Re: systemtap broken by removal of register_timer_hook
- References: <20130403075017 dot GA2534 at suse dot de> <CAFTL4hyYezB2ZxM-GJ70VoxOeRSG64V6u+nX2hTuhF30R-GdPg__32168 dot 962484184$1364986928$gmane$org at mail dot gmail dot com> <y0mvc83u79f dot fsf at fche dot csb> <CAFTL4hxx_GHoa4uguSAtY0A=cC43qJPKvpqaoguS-WAjFj+HSw at mail dot gmail dot com> <20130403144428 dot GA15432 at redhat dot com> <CAFTL4hy+U-dLPwGR8BcZt=C8Tug-jvh+24epadfte7Ci2cDU5Q at mail dot gmail dot com> <20130419144655 dot GD8308 at redhat dot com>
On Fri, Apr 19, 2013 at 10:46:55AM -0400, Frank Ch. Eigler wrote:
> Hi, Frederic -
>
>
> > > How about this?
> > >
> > > Author: Frank Ch. Eigler <fche@redhat.com>
> > > Date: Wed Apr 3 10:35:21 2013 -0400
> > >
> > > profiling: add profile_tick tracepoint
> > > [...]
>
> > It would be better not to tie this to CONFIG_PROFILING.
> > A tracepoint in update_process_times() instead would be great but it's
> > sometimes called several times in a tick from some archs.
> > Probably we need something like:
> >
> > static inline tick_trace(struct pt_regs *regs)
> > {
> > trace_timer_tick(regs);
> > profile_tick(CPU_PROFILING);
> > }
>
> I looked into this, but found no natural place to define such an
> inline function from which to call into a tracepoint, without having
> to #include the <event/FOO.h> file many times.
You could include it from linux/profile.h or linux/tick.h and
define profile_tick to "{ trace_tick(); __profile_tick()}" .
But in a second thought, using a tracepoint in a general purpose header
resulted in bad circular headers dependency in the past, we had bitter
experiences with trace_softirq_raise for example.
> Nor does it seem
> appropriate to do the identical #define CREATE_TRACE_POINTSw part from
> all the different arch/.../*.c files that may call into that inline.
>
> If you'd like to stick to this idea, please advise further where you
> think the tracepoint definition & declarations should go.
>
> In the alternative, here is v2 of the patch, just changing the
> tracepoint-printing argument as suggested by jistone.
But your tracepoint still depends on CONFIG_PROFILING and I would
really like to avoid that.
How about creating trace_tick() in include/trace/events/timer.h
and call it from tick_periodic() and tick_sched_handle().
This only leaves the archs that don't support generic clockevents
behind. This should be no big deal, they can integrate this tracepoint
later if they need to.
Thanks.