[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <y0mwsisitcy.fsf@ton.toronto.redhat.com>
Date: Thu, 07 Aug 2008 14:15:57 -0400
From: fche@...hat.com (Frank Ch. Eigler)
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
James Bottomley <James.Bottomley@...senPartnership.com>,
akpm@...ux-foundation.org, Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, ltt-dev@...ts.casi.polymtl.ca
Subject: Re: LTTng finds abnormally long APIC interrupt handler : 58.2 ms
Steven Rostedt <rostedt@...dmis.org> writes:
> [...]
>> It all holds in a small module. Having the ability to connect any marker
>> on any generic probe from the lttng marker interface has been very
>> useful to do all this. Actually, this module has to be built into the
>> kernel because ftrace does not permit breeing the trace_ops data
>> structure. :/
>
> I did this purposely. The reason is that there is no safe way to release
> the trace_ops, because you never know if something is in the function
> you pointed to. If you remove the module after that, it crashes.
>
> I've been thinking of exporting it, and make it so that once you
> register something to the trace_ops, I'll up the module count, and never
> let that module unload.
This issue will need some sort of resolution if systemtap is to be
able to hook up to ftrace. Perhaps we could have a second/nested API
that suffers the costs of explicit reference counting, but does permit
dynamic attach and robust detach.
- FChE
--
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