On Mon, 6 May 2019 00:39:15 +0200 Viktor Rosendahl <viktor.rosend...@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
