On Mon, Apr 23, 2018 at 10:59:43AM -0400, Mathieu Desnoyers wrote: > ----- On Apr 23, 2018, at 10:53 AM, rostedt rostedt@xxxxxxxxxxx wrote: > > > 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. > > The main open question here is whether we want one SRCU grace period > domain per SRCU tracepoint definition, or just one SRCU domain for all > SRCU tracepoints would be fine. > > I'm not sure what we would gain by having the extra granularity provided > by one SRCU grace period domain per tracepoint, and having a single SRCU > domain for all SRCU tracepoints makes it easy to batch grace period after > bulk tracepoint modifications. I don't see how having multiple SRCU domains would help anything, but perhaps I am missing something basic. thanx, Paul -- 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
