Messages in this thread | | | Date | Sun, 5 May 2019 19:01:33 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH v2 1/4] ftrace: Implement fs notification for preempt/irqsoff tracers |
| |
On Mon, 6 May 2019 00:39:15 +0200 Viktor Rosendahl <viktor.rosendahl@gmail.com> wrote:
> Can you explain more precisely what you agree with? > > The general idea of being able to trace bursts of latencies?
One thing I have an issue with the current approach is the use of the trace file for this.
> > Or the slightly more specific idea of notifying user space when > /sys/kernel/debug/tracing/trace has new data, and let user space do the rest? > > > We do have a notification mechanism already in the form of trace_pipe. Can we > > not improve that in some way to be notified of a new trace data? In theory, > > the trace_pipe does fit into the description in the documentation: "Reads > > from this file will block until new data is retrieved" > > > > I am not quite sure what kind of solution you are after here. Could you be more > specific? > > I think that it would be weird if we used trace_pipe to send a message with > the meaning "new data is available in the trace file". To me this would seem > like (re)inventing a special purpose alternative to inotify. > > Another option would be to allow the user to consume the the latency traces > directly from trace_pipe, without using the trace file. This would make sense > to me and would indeed be a much better solution. If somebody is able to make > such an implementation I am all for it. > > However, I do not know how to do this. I believe that it would lead towards a > significant rewrite of the latency tracers, probably also how the ftrace > buffering works. >
Hmm, what about adding a notifier to tracing_max_latency instead? And do it not as a config option, but have it always enabled. It would send a notification when it changes, and that only happens when there's a new max latency. Would that work for you?
-- Steve
| |