On Mon, 23 Apr 2018 10:31:28 -0400 (EDT) Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > I've been wanting to introduce an alternative tracepoint instrumentation > "flavor" for e.g. system call entry/exit which rely on SRCU rather than > sched-rcu (preempt-off). This would allow taking faults within the instrumentation > probe, which makes lots of things easier when fetching data from user-space > upon system call entry/exit. This could also be used to cleanly instrument > the idle loop. I'd be OK with such an approach. And I don't think it would be that hard to implement. It could be similar to the rcu_idle() tracepoints, where each flavor simply passes in what protection it uses for DO_TRACE(). We could do linker tricks to tell the tracepoint.c code how the tracepoint is protected (add section code, that could be read to update flags in the tracepoint). Of course modules that have tracepoints could only use the standard preempt ones. That is, if trace_##event##_srcu(trace_##event##_sp, PARAMS), is used, then the trace_##event##_sp would need to be created somewhere. The use of trace_##event##_srcu() would create a section entry, and on boot up we can see that the use of this tracepoint requires srcu protection with a pointer to the trace_##event##_sp srcu_struct. This could be used to make sure that trace_#event() call isn't done multiple times that uses two different protection flavors. I'm just brain storming the idea, and I'm sure I screwed up something above, but I do believe it is feasible. > > I would be tempted to proceed carefully and introduce a new kind of SRCU > tracepoint rather than changing all existing ones from sched-rcu to SRCU > though. Agreed. > > So the lockdep stuff could use the SRCU tracepoint flavor, which I guess > would be faster than the rcu_irq_enter_*(). Also agree. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
