[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted
On Thu, Jan 22, 2015 at 03:16:57PM -0500, Steven Rostedt wrote: > > [ Added Paul McKenney ] > > On Thu, 22 Jan 2015 19:39:13 +0100 > "Luis R. Rodriguez" <mcgrof@xxxxxxxx> wrote: > > > > Why not make this a tracepoint? Then you can enable it only when you > > > want to. As tracepoints are also hooks, you could add you own code that > > > hooks to it and does a printk as well. The advantage of doing it via a > > > tracepoint is that you can turn it on and off regardless of what the > > > loglevel is set at. > > > > This uses NOKPROBE_SYMBOL and notrace since based on Andy's advice > > we are not confident that tracing and kprobes are safe to use in what > > might be an extended RCU quiescent state (i.e. where we're outside > > irq_enter and irq_exit). > > We have trace_*_rcuidle() for such cases. > > That is, you create the tracepoint just the same, and instead of having > trace_foo(), if you are in a known area that is outside of rcu viewing, > you use trace_foo_rcuidle() and it will tell RCU "hey, there's something > here that may need RCU, so look at me!" What Steve said! Also, there is an rcu_is_watching() API member that can tell you whether or not RCU is paying attention at a given point. Or test with CONFIG_PROVE_RCU, in which case lockdep will yell at you if you should have used the _rcuidle() form of the tracing hooks. ;-) Thanx, Paul > Also, please remove the "notrace", because function tracing goes an > extra step to not require RCU being visible. The only thing you get > with notrace is not being able to trace an otherwise traceable function. > > -- Steve > > > > > > That is, if there is any practical use for that message. Tracing just > > > sched_switch will give you the same info. > > > > IMHO it may be more useful if we knew exactly what hypercalls were > > being preempted but perhaps all that can be left as a secondary > > exercise and for now I'll just nuke the print. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |