Messages in this thread | | | Subject | Re: [ANNOUNCE] New utility: 'trace' | From | Tom Zanussi <> | Date | Wed, 17 Nov 2010 09:33:21 -0600 |
| |
On Wed, 2010-11-17 at 15:11 +0100, Peter Zijlstra wrote: > On Wed, 2010-11-17 at 15:00 +0100, Ingo Molnar wrote: > > > But yes, it is functional. > > > > I suspect that is what matters mostly - unless you think that it's impossible to > > have a sane implementation of it, if the users come. > > I'm not sure, I raised the point several times, and I think Steve and > Tom though it was possible to implement sanely, but I'm not sure if it > was expression invariant (the fix that is). > > It would be very good to have a definite answer on that. > > The idea was to not let the filter engine work on the trace data (once > its gathered) but on the trace argument right at the beginning of the > tracepoint callchain, since some of the trace data is an expression of > the trace argument (say next->prio instead of next), the trace > expression wouldn't stay invariant, you'd have to write a different > filter for the same effect. >
IIRC, I think the conclusion we came to was that it could be done mechanically if for example the right-hand-side of an assignment in TP_fast_assign() only involved a simple variable assignment, but as Steve pointed out, some assignments are more complicated than that.
For example, in the sched_switch tracepoint assignments:
__entry->prev_prio = prev->prio; __entry->prev_state = __trace_sched_switch_state(prev);
so the prev_prio should be able to be tested 'in-line' but the prev_state would require a temporary buffer to write the value into before doing the test as mentioned by Steve. At which point you're no further ahead (in that case) than the current situation...
Tom
> So I think it would be wise to make this change sooner rather than > later.
| |