On Fri, 2013-07-26 at 09:17 -0400, Steven Rostedt wrote: > On Fri, 2013-07-26 at 15:06 +0200, Johannes Berg wrote: > > On Fri, 2013-07-26 at 08:28 -0400, Steven Rostedt wrote: > > > Ah, yes, that'd work. I was considering putting it into the trace event > > handling itself so I don't have to allocate those buffers and put the > > handling into every tracepoint, but I don't know how that'd work with > > interrupts coming in. > > If you create helper functions, it shouldn't be too hard. True, and I could even export them somewhere to share the buffers between all the different subsystems that might use this. > > If we assume that interrupts coming in in the middle of a tracepoint > > should be rare, we could do something like > > > > * allocate max buffer in on the tracing ringbuffer page > > * write data into it > > * if no interrupt came in, reduce reservation > > > > but I'm not sure how to implement step 3 :) > > > > It's possible to reduce the ring buffer, it's just not implemented. I'm > not sure I want to do that either. Interrupts coming in is not so rare > as it can be any interrupt being traced. This means your tracepoints > will likely waste a lot of buffer space if you are tracing interrupts as > well. Well, right now I can live with allocation 110 bytes for each tracepoint, this would just optimise it down. If I was in the middle of writing one such event while an interrupt came in, I'd not be able to reduce the ring-buffer allocation again. I doubt that an interrupt would come in much of the time between allocating the new event and deallocating it partially. The more difficult question would seem to be whether or not we can reliably detect an interrupt having written another event. Also, this would save the memcpy() your scheme had. Anyway, I'm fine with the current status quo, but if more people want to trace variable length things like formatted strings I think it might make sense to add some way of making that more efficient. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
