Re: Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
* Paul E. McKenney ([EMAIL PROTECTED]) wrote: > On Tue, Feb 19, 2008 at 03:33:26PM -0500, Mathieu Desnoyers wrote: > > * Jan Kiszka ([EMAIL PROTECTED]) wrote: > > > Paul E. McKenney wrote: > > > > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > > > >> K. Prasad wrote: > > > >>> Hi Ingo, > > > >>> Please accept these patches into the rt tree which convert the > > > >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into > > > >>> markers. > > > >>> > > > >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > > >>> > > > >>> Along with marker transition, the RCU Tracing infrastructure has also > > > >>> been modularised to be built as a kernel module, thereby enabling > > > >>> runtime changes to the RCU Tracing infrastructure. > > > >>> > > > >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in > > > >>> rcupreempt.c into markers. > > > >>> > > > >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > > > >>> rcupreempt-boost.c into markers. > > > >>> > > > >> I have a technical problem with marker-based RCU tracing: It causes > > > >> nasty recursions with latest multi-probe marker patches (sorry, no link > > > >> at hand, can be found in latest LTTng, maybe also already in -mm). > > > >> Those > > > >> patches introduce a marker probe trampoline like this: > > > >> > > > >> void marker_probe_cb(const struct marker *mdata, void *call_private, > > > >>const char *fmt, ...) > > > >> { > > > >>va_list args; > > > >>char ptype; > > > >> > > > >>/* > > > >> * rcu_read_lock does two things : disabling preemption to make > > > >> sure the > > > >> * teardown of the callbacks can be done correctly when they > > > >> are in > > > >> * modules and they insure RCU read coherency. > > > >> */ > > > >>rcu_read_lock(); > > > >>preempt_disable(); > > > >>... > > > >> > > > >> Can we do multi-probe with pure preempt_disable/enable protection? I > > > >> guess it's fine with classic RCU, but what about preemptible RCU? Any > > > >> suggestion appreciated! > > > > > > > > If you substitute synchronize_sched() for synchronize_rcu(), this should > > > > work fine. Of course, this approach would cause RCU tracing to degrade > > > > latencies somewhat in -rt. > > > > > > > > If tracing is using call_rcu(), we will need to add a call_sched() > > > > or some such. > > > > > > You mean something like "#define call_sched call_rcu_classic"? > > > > > > I just learned that there is another reason for killing > > > rcu_read_lock&friends from the marker probes: It can deadlock on -rt > > > with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => > > > rcu_read_unlock triggers unboost => stuck on rq_lock :( ). > > > > > > > Yep, ok, let's do this : > > > > in include/linux/rcupdate.h > > > > #ifndef PREEMPT_RT > > #define call_sched call_rcu > > #else > > #define call_sched call_rcu_classic > > #endif > > > > And I'll adapt the markers accordingly. > > Good point, this will indeed work for 2.6.24-rt1! > > Will need to do a bit more for 2.6.25-rc1. My current thought is to > provide a kernel thread that loops over the CPUs, advancing/invoking > per-CPU lists of callbacks as it does so. Then call_sched() would simply > enqueue its callback on the current CPU's next list. > I just noticed that my multiple probes support patch, that just got into mainline, does not include the fixes I did you asked for (which includes protecting with rcu_read_lock). I guess Andrew did not notice the patch. Therefore, I think we'll need to address this pretty soon to make the markers play nicely with CONFIG_PREEMPT_RCU. Mathieu > Thanx, Paul -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
On Tue, Feb 19, 2008 at 05:03:18PM -0500, Mathieu Desnoyers wrote: > * Paul E. McKenney ([EMAIL PROTECTED]) wrote: > > On Tue, Feb 19, 2008 at 05:27:40PM +0100, Jan Kiszka wrote: > > > Paul E. McKenney wrote: > > > > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > > > >> K. Prasad wrote: > > > >>> Hi Ingo, > > > >>> Please accept these patches into the rt tree which convert the > > > >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into > > > >>> markers. > > > >>> > > > >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > > >>> > > > >>> Along with marker transition, the RCU Tracing infrastructure has also > > > >>> been modularised to be built as a kernel module, thereby enabling > > > >>> runtime changes to the RCU Tracing infrastructure. > > > >>> > > > >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in > > > >>> rcupreempt.c into markers. > > > >>> > > > >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > > > >>> rcupreempt-boost.c into markers. > > > >>> > > > >> I have a technical problem with marker-based RCU tracing: It causes > > > >> nasty recursions with latest multi-probe marker patches (sorry, no link > > > >> at hand, can be found in latest LTTng, maybe also already in -mm). > > > >> Those > > > >> patches introduce a marker probe trampoline like this: > > > >> > > > >> void marker_probe_cb(const struct marker *mdata, void *call_private, > > > >>const char *fmt, ...) > > > >> { > > > >>va_list args; > > > >>char ptype; > > > >> > > > >>/* > > > >> * rcu_read_lock does two things : disabling preemption to make > > > >> sure the > > > >> * teardown of the callbacks can be done correctly when they > > > >> are in > > > >> * modules and they insure RCU read coherency. > > > >> */ > > > >>rcu_read_lock(); > > > >>preempt_disable(); > > > >>... > > > >> > > > >> Can we do multi-probe with pure preempt_disable/enable protection? I > > > >> guess it's fine with classic RCU, but what about preemptible RCU? Any > > > >> suggestion appreciated! > > > > > > > > If you substitute synchronize_sched() for synchronize_rcu(), this should > > > > work fine. Of course, this approach would cause RCU tracing to degrade > > > > latencies somewhat in -rt. > > > > > > > > If tracing is using call_rcu(), we will need to add a call_sched() > > > > or some such. > > > > > > You mean something like "#define call_sched call_rcu_classic"? > > > > This would work for Classic RCU. For preemptible RCU, a bit more > > work is needed. > > > > > I just learned that there is another reason for killing > > > rcu_read_lock&friends from the marker probes: It can deadlock on -rt > > > with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => > > > rcu_read_unlock triggers unboost => stuck on rq_lock :( ). > > > > OK, good to know. Guess we need a call_sched() for -rt and for > > preemptible RCU sooner rather than later... > > > > Yup, I would need call_sched() and sched_barrier(). Ah, good point, kprobes does indeed use modules! Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
On Tue, Feb 19, 2008 at 03:33:26PM -0500, Mathieu Desnoyers wrote: > * Jan Kiszka ([EMAIL PROTECTED]) wrote: > > Paul E. McKenney wrote: > > > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > > >> K. Prasad wrote: > > >>> Hi Ingo, > > >>> Please accept these patches into the rt tree which convert the > > >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into > > >>> markers. > > >>> > > >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > >>> > > >>> Along with marker transition, the RCU Tracing infrastructure has also > > >>> been modularised to be built as a kernel module, thereby enabling > > >>> runtime changes to the RCU Tracing infrastructure. > > >>> > > >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in > > >>> rcupreempt.c into markers. > > >>> > > >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > > >>> rcupreempt-boost.c into markers. > > >>> > > >> I have a technical problem with marker-based RCU tracing: It causes > > >> nasty recursions with latest multi-probe marker patches (sorry, no link > > >> at hand, can be found in latest LTTng, maybe also already in -mm). Those > > >> patches introduce a marker probe trampoline like this: > > >> > > >> void marker_probe_cb(const struct marker *mdata, void *call_private, > > >> const char *fmt, ...) > > >> { > > >> va_list args; > > >> char ptype; > > >> > > >> /* > > >> * rcu_read_lock does two things : disabling preemption to make sure the > > >> * teardown of the callbacks can be done correctly when they are in > > >> * modules and they insure RCU read coherency. > > >> */ > > >> rcu_read_lock(); > > >> preempt_disable(); > > >> ... > > >> > > >> Can we do multi-probe with pure preempt_disable/enable protection? I > > >> guess it's fine with classic RCU, but what about preemptible RCU? Any > > >> suggestion appreciated! > > > > > > If you substitute synchronize_sched() for synchronize_rcu(), this should > > > work fine. Of course, this approach would cause RCU tracing to degrade > > > latencies somewhat in -rt. > > > > > > If tracing is using call_rcu(), we will need to add a call_sched() > > > or some such. > > > > You mean something like "#define call_sched call_rcu_classic"? > > > > I just learned that there is another reason for killing > > rcu_read_lock&friends from the marker probes: It can deadlock on -rt > > with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => > > rcu_read_unlock triggers unboost => stuck on rq_lock :( ). > > > > Yep, ok, let's do this : > > in include/linux/rcupdate.h > > #ifndef PREEMPT_RT > #define call_sched call_rcu > #else > #define call_sched call_rcu_classic > #endif > > And I'll adapt the markers accordingly. Good point, this will indeed work for 2.6.24-rt1! Will need to do a bit more for 2.6.25-rc1. My current thought is to provide a kernel thread that loops over the CPUs, advancing/invoking per-CPU lists of callbacks as it does so. Then call_sched() would simply enqueue its callback on the current CPU's next list. Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
* Paul E. McKenney ([EMAIL PROTECTED]) wrote: > On Tue, Feb 19, 2008 at 05:27:40PM +0100, Jan Kiszka wrote: > > Paul E. McKenney wrote: > > > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > > >> K. Prasad wrote: > > >>> Hi Ingo, > > >>> Please accept these patches into the rt tree which convert the > > >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into > > >>> markers. > > >>> > > >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > >>> > > >>> Along with marker transition, the RCU Tracing infrastructure has also > > >>> been modularised to be built as a kernel module, thereby enabling > > >>> runtime changes to the RCU Tracing infrastructure. > > >>> > > >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in > > >>> rcupreempt.c into markers. > > >>> > > >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > > >>> rcupreempt-boost.c into markers. > > >>> > > >> I have a technical problem with marker-based RCU tracing: It causes > > >> nasty recursions with latest multi-probe marker patches (sorry, no link > > >> at hand, can be found in latest LTTng, maybe also already in -mm). Those > > >> patches introduce a marker probe trampoline like this: > > >> > > >> void marker_probe_cb(const struct marker *mdata, void *call_private, > > >> const char *fmt, ...) > > >> { > > >> va_list args; > > >> char ptype; > > >> > > >> /* > > >> * rcu_read_lock does two things : disabling preemption to make sure the > > >> * teardown of the callbacks can be done correctly when they are in > > >> * modules and they insure RCU read coherency. > > >> */ > > >> rcu_read_lock(); > > >> preempt_disable(); > > >> ... > > >> > > >> Can we do multi-probe with pure preempt_disable/enable protection? I > > >> guess it's fine with classic RCU, but what about preemptible RCU? Any > > >> suggestion appreciated! > > > > > > If you substitute synchronize_sched() for synchronize_rcu(), this should > > > work fine. Of course, this approach would cause RCU tracing to degrade > > > latencies somewhat in -rt. > > > > > > If tracing is using call_rcu(), we will need to add a call_sched() > > > or some such. > > > > You mean something like "#define call_sched call_rcu_classic"? > > This would work for Classic RCU. For preemptible RCU, a bit more > work is needed. > > > I just learned that there is another reason for killing > > rcu_read_lock&friends from the marker probes: It can deadlock on -rt > > with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => > > rcu_read_unlock triggers unboost => stuck on rq_lock :( ). > > OK, good to know. Guess we need a call_sched() for -rt and for > preemptible RCU sooner rather than later... > Yup, I would need call_sched() and sched_barrier(). Thanks, Mathieu > Thanx, Paul -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
On Tue, Feb 19, 2008 at 05:27:40PM +0100, Jan Kiszka wrote: > Paul E. McKenney wrote: > > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > >> K. Prasad wrote: > >>> Hi Ingo, > >>> Please accept these patches into the rt tree which convert the > >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into > >>> markers. > >>> > >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > >>> > >>> Along with marker transition, the RCU Tracing infrastructure has also > >>> been modularised to be built as a kernel module, thereby enabling > >>> runtime changes to the RCU Tracing infrastructure. > >>> > >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in > >>> rcupreempt.c into markers. > >>> > >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > >>> rcupreempt-boost.c into markers. > >>> > >> I have a technical problem with marker-based RCU tracing: It causes > >> nasty recursions with latest multi-probe marker patches (sorry, no link > >> at hand, can be found in latest LTTng, maybe also already in -mm). Those > >> patches introduce a marker probe trampoline like this: > >> > >> void marker_probe_cb(const struct marker *mdata, void *call_private, > >>const char *fmt, ...) > >> { > >>va_list args; > >>char ptype; > >> > >>/* > >> * rcu_read_lock does two things : disabling preemption to make sure the > >> * teardown of the callbacks can be done correctly when they are in > >> * modules and they insure RCU read coherency. > >> */ > >>rcu_read_lock(); > >>preempt_disable(); > >>... > >> > >> Can we do multi-probe with pure preempt_disable/enable protection? I > >> guess it's fine with classic RCU, but what about preemptible RCU? Any > >> suggestion appreciated! > > > > If you substitute synchronize_sched() for synchronize_rcu(), this should > > work fine. Of course, this approach would cause RCU tracing to degrade > > latencies somewhat in -rt. > > > > If tracing is using call_rcu(), we will need to add a call_sched() > > or some such. > > You mean something like "#define call_sched call_rcu_classic"? This would work for Classic RCU. For preemptible RCU, a bit more work is needed. > I just learned that there is another reason for killing > rcu_read_lock&friends from the marker probes: It can deadlock on -rt > with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => > rcu_read_unlock triggers unboost => stuck on rq_lock :( ). OK, good to know. Guess we need a call_sched() for -rt and for preemptible RCU sooner rather than later... Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
* Jan Kiszka ([EMAIL PROTECTED]) wrote: > Paul E. McKenney wrote: > > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > >> K. Prasad wrote: > >>> Hi Ingo, > >>> Please accept these patches into the rt tree which convert the > >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into > >>> markers. > >>> > >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > >>> > >>> Along with marker transition, the RCU Tracing infrastructure has also > >>> been modularised to be built as a kernel module, thereby enabling > >>> runtime changes to the RCU Tracing infrastructure. > >>> > >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in > >>> rcupreempt.c into markers. > >>> > >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > >>> rcupreempt-boost.c into markers. > >>> > >> I have a technical problem with marker-based RCU tracing: It causes > >> nasty recursions with latest multi-probe marker patches (sorry, no link > >> at hand, can be found in latest LTTng, maybe also already in -mm). Those > >> patches introduce a marker probe trampoline like this: > >> > >> void marker_probe_cb(const struct marker *mdata, void *call_private, > >>const char *fmt, ...) > >> { > >>va_list args; > >>char ptype; > >> > >>/* > >> * rcu_read_lock does two things : disabling preemption to make sure the > >> * teardown of the callbacks can be done correctly when they are in > >> * modules and they insure RCU read coherency. > >> */ > >>rcu_read_lock(); > >>preempt_disable(); > >>... > >> > >> Can we do multi-probe with pure preempt_disable/enable protection? I > >> guess it's fine with classic RCU, but what about preemptible RCU? Any > >> suggestion appreciated! > > > > If you substitute synchronize_sched() for synchronize_rcu(), this should > > work fine. Of course, this approach would cause RCU tracing to degrade > > latencies somewhat in -rt. > > > > If tracing is using call_rcu(), we will need to add a call_sched() > > or some such. > > You mean something like "#define call_sched call_rcu_classic"? > > I just learned that there is another reason for killing > rcu_read_lock&friends from the marker probes: It can deadlock on -rt > with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => > rcu_read_unlock triggers unboost => stuck on rq_lock :( ). > Yep, ok, let's do this : in include/linux/rcupdate.h #ifndef PREEMPT_RT #define call_sched call_rcu #else #define call_sched call_rcu_classic #endif And I'll adapt the markers accordingly. Mathieu > Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Markers: multi-probe locking fun (was: Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II)
Paul E. McKenney wrote: > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: >> K. Prasad wrote: >>> Hi Ingo, >>> Please accept these patches into the rt tree which convert the >>> existing RCU tracing mechanism for Preempt RCU and RCU Boost into >>> markers. >>> >>> These patches are based upon the 2.6.24-rc5-rt1 kernel tree. >>> >>> Along with marker transition, the RCU Tracing infrastructure has also >>> been modularised to be built as a kernel module, thereby enabling >>> runtime changes to the RCU Tracing infrastructure. >>> >>> Patch [1/2] - Patch that converts the Preempt RCU tracing in >>> rcupreempt.c into markers. >>> >>> Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in >>> rcupreempt-boost.c into markers. >>> >> I have a technical problem with marker-based RCU tracing: It causes >> nasty recursions with latest multi-probe marker patches (sorry, no link >> at hand, can be found in latest LTTng, maybe also already in -mm). Those >> patches introduce a marker probe trampoline like this: >> >> void marker_probe_cb(const struct marker *mdata, void *call_private, >> const char *fmt, ...) >> { >> va_list args; >> char ptype; >> >> /* >> * rcu_read_lock does two things : disabling preemption to make sure the >> * teardown of the callbacks can be done correctly when they are in >> * modules and they insure RCU read coherency. >> */ >> rcu_read_lock(); >> preempt_disable(); >> ... >> >> Can we do multi-probe with pure preempt_disable/enable protection? I >> guess it's fine with classic RCU, but what about preemptible RCU? Any >> suggestion appreciated! > > If you substitute synchronize_sched() for synchronize_rcu(), this should > work fine. Of course, this approach would cause RCU tracing to degrade > latencies somewhat in -rt. > > If tracing is using call_rcu(), we will need to add a call_sched() > or some such. You mean something like "#define call_sched call_rcu_classic"? I just learned that there is another reason for killing rcu_read_lock&friends from the marker probes: It can deadlock on -rt with PREEMPT_RCU_BOOST (hit probe inside rq-lock protected region => rcu_read_unlock triggers unboost => stuck on rq_lock :( ). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II
* Paul E. McKenney ([EMAIL PROTECTED]) wrote: > On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > > K. Prasad wrote: > > > Hi Ingo, > > > Please accept these patches into the rt tree which convert the > > > existing RCU tracing mechanism for Preempt RCU and RCU Boost into > > > markers. > > > > > > These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > > > > > Along with marker transition, the RCU Tracing infrastructure has also > > > been modularised to be built as a kernel module, thereby enabling > > > runtime changes to the RCU Tracing infrastructure. > > > > > > Patch [1/2] - Patch that converts the Preempt RCU tracing in > > > rcupreempt.c into markers. > > > > > > Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > > > rcupreempt-boost.c into markers. > > > > > > > I have a technical problem with marker-based RCU tracing: It causes > > nasty recursions with latest multi-probe marker patches (sorry, no link > > at hand, can be found in latest LTTng, maybe also already in -mm). Those > > patches introduce a marker probe trampoline like this: > > > > void marker_probe_cb(const struct marker *mdata, void *call_private, > > const char *fmt, ...) > > { > > va_list args; > > char ptype; > > > > /* > > * rcu_read_lock does two things : disabling preemption to make sure the > > * teardown of the callbacks can be done correctly when they are in > > * modules and they insure RCU read coherency. > > */ > > rcu_read_lock(); > > preempt_disable(); > > ... > > > > Can we do multi-probe with pure preempt_disable/enable protection? I > > guess it's fine with classic RCU, but what about preemptible RCU? Any > > suggestion appreciated! > > If you substitute synchronize_sched() for synchronize_rcu(), this should > work fine. Of course, this approach would cause RCU tracing to degrade > latencies somewhat in -rt. > > If tracing is using call_rcu(), we will need to add a call_sched() > or some such. > Yes, I use call_rcu, so I guess a call_sched would be useful here. Mathieu > Thanx, Paul > > > Jan > > > > PS: You will run into this issue if you try to marry latest -rt with > > latest LTTng. Straightforward workaround is to comment-out any RCU > > trace_mark occurrences. > > > > -- > > Siemens AG, Corporate Technology, CT SE 2 > > Corporate Competence Center Embedded Linux -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II
On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote: > K. Prasad wrote: > > Hi Ingo, > > Please accept these patches into the rt tree which convert the > > existing RCU tracing mechanism for Preempt RCU and RCU Boost into > > markers. > > > > These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > > > Along with marker transition, the RCU Tracing infrastructure has also > > been modularised to be built as a kernel module, thereby enabling > > runtime changes to the RCU Tracing infrastructure. > > > > Patch [1/2] - Patch that converts the Preempt RCU tracing in > > rcupreempt.c into markers. > > > > Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > > rcupreempt-boost.c into markers. > > > > I have a technical problem with marker-based RCU tracing: It causes > nasty recursions with latest multi-probe marker patches (sorry, no link > at hand, can be found in latest LTTng, maybe also already in -mm). Those > patches introduce a marker probe trampoline like this: > > void marker_probe_cb(const struct marker *mdata, void *call_private, > const char *fmt, ...) > { > va_list args; > char ptype; > > /* >* rcu_read_lock does two things : disabling preemption to make sure the >* teardown of the callbacks can be done correctly when they are in >* modules and they insure RCU read coherency. >*/ > rcu_read_lock(); > preempt_disable(); > ... > > Can we do multi-probe with pure preempt_disable/enable protection? I > guess it's fine with classic RCU, but what about preemptible RCU? Any > suggestion appreciated! If you substitute synchronize_sched() for synchronize_rcu(), this should work fine. Of course, this approach would cause RCU tracing to degrade latencies somewhat in -rt. If tracing is using call_rcu(), we will need to add a call_sched() or some such. Thanx, Paul > Jan > > PS: You will run into this issue if you try to marry latest -rt with > latest LTTng. Straightforward workaround is to comment-out any RCU > trace_mark occurrences. > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II
K. Prasad wrote: > Hi Ingo, > Please accept these patches into the rt tree which convert the > existing RCU tracing mechanism for Preempt RCU and RCU Boost into > markers. > > These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > Along with marker transition, the RCU Tracing infrastructure has also > been modularised to be built as a kernel module, thereby enabling > runtime changes to the RCU Tracing infrastructure. > > Patch [1/2] - Patch that converts the Preempt RCU tracing in > rcupreempt.c into markers. > > Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > rcupreempt-boost.c into markers. > > Thanks, > K.Prasad > ([EMAIL PROTECTED]) The correct marker annotation for "no arguments" is MARK_NOARGS. Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]> --- kernel/rcupreempt-boost.c | 24 kernel/rcupreempt.c | 42 +- 2 files changed, 33 insertions(+), 33 deletions(-) Index: b/kernel/rcupreempt-boost.c === --- a/kernel/rcupreempt-boost.c +++ b/kernel/rcupreempt-boost.c @@ -57,10 +57,10 @@ static void rcu_boost_task(struct task_s WARN_ON(!irqs_disabled()); WARN_ON_SMP(!spin_is_locked(&task->pi_lock)); - trace_mark(task_boost_called, "NULL"); + trace_mark(task_boost_called, MARK_NOARGS); if (task->rcu_prio < task->prio) { - trace_mark(task_boosted, "NULL"); + trace_mark(task_boosted, MARK_NOARGS); task_setprio(task, task->rcu_prio); } } @@ -84,7 +84,7 @@ void __rcu_preempt_boost(void) WARN_ON(!current->rcu_read_lock_nesting); - trace_mark(boost_called, "NULL"); + trace_mark(boost_called, MARK_NOARGS); /* check to see if we are already boosted */ if (unlikely(rcu_is_boosted(curr))) @@ -102,7 +102,7 @@ void __rcu_preempt_boost(void) curr->rcub_rbdp = rbd; - trace_mark(try_boost, "NULL"); + trace_mark(try_boost, MARK_NOARGS); prio = rt_mutex_getprio(curr); @@ -111,7 +111,7 @@ void __rcu_preempt_boost(void) if (prio <= rbd->rbs_prio) goto out; - trace_mark(boosted, "NULL"); + trace_mark(boosted, MARK_NOARGS); curr->rcu_prio = rbd->rbs_prio; rcu_boost_task(curr); @@ -136,7 +136,7 @@ void __rcu_preempt_unboost(void) int prio; unsigned long flags; - trace_mark(unboost_called, "NULL"); + trace_mark(unboost_called, MARK_NOARGS); /* if not boosted, then ignore */ if (likely(!rcu_is_boosted(curr))) @@ -174,7 +174,7 @@ void __rcu_preempt_unboost(void) list_del_init(&curr->rcub_entry); - trace_mark(unboosted, "NULL"); + trace_mark(unboosted, MARK_NOARGS); curr->rcu_prio = MAX_PRIO; @@ -235,7 +235,7 @@ static int __rcu_boost_readers(struct rc * Another task may have taken over. */ if (curr->rcu_preempt_counter != rcu_boost_counter) { - trace_mark(over_taken, "NULL"); + trace_mark(over_taken, MARK_NOARGS); return 1; } @@ -266,7 +266,7 @@ void rcu_boost_readers(void) prio = rt_mutex_getprio(curr); - trace_mark(try_boost_readers, "NULL"); + trace_mark(try_boost_readers, MARK_NOARGS); if (prio >= rcu_boost_prio) { /* already boosted */ @@ -276,7 +276,7 @@ void rcu_boost_readers(void) rcu_boost_prio = prio; - trace_mark(boost_readers, "NULL"); + trace_mark(boost_readers, MARK_NOARGS); /* Flag that we are the one to unboost */ curr->rcu_preempt_counter = ++rcu_boost_counter; @@ -309,12 +309,12 @@ void rcu_unboost_readers(void) spin_lock_irqsave(&rcu_boost_wake_lock, flags); - trace_mark(try_unboost_readers, "NULL"); + trace_mark(try_unboost_readers, MARK_NOARGS); if (current->rcu_preempt_counter != rcu_boost_counter) goto out; - trace_mark(unboost_readers, "NULL"); + trace_mark(unboost_readers, MARK_NOARGS); /* * We could also put in something that Index: b/kernel/rcupreempt.c === --- a/kernel/rcupreempt.c +++ b/kernel/rcupreempt.c @@ -308,7 +308,7 @@ static void __rcu_advance_callbacks(stru if (rdp->waitlist[GP_STAGES - 1] != NULL) { *rdp->donetail = rdp->waitlist[GP_STAGES - 1]; rdp->donetail = rdp->waittail[GP_STAGES - 1]; - trace_mark(rcupreempt_trace_move2done, "NULL"); + trace_mark(rcupreempt_trace_move2done, MARK_NOARGS); } for (i = GP_STAGES - 2; i >= 0; i--) { if (rdp->waitlist[i] != NULL) { @@ -327,7 +327
Re: [PATCH 0/2] Markers Implementation for RCU Tracing - Ver II
K. Prasad wrote: > Hi Ingo, > Please accept these patches into the rt tree which convert the > existing RCU tracing mechanism for Preempt RCU and RCU Boost into > markers. > > These patches are based upon the 2.6.24-rc5-rt1 kernel tree. > > Along with marker transition, the RCU Tracing infrastructure has also > been modularised to be built as a kernel module, thereby enabling > runtime changes to the RCU Tracing infrastructure. > > Patch [1/2] - Patch that converts the Preempt RCU tracing in > rcupreempt.c into markers. > > Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in > rcupreempt-boost.c into markers. > I have a technical problem with marker-based RCU tracing: It causes nasty recursions with latest multi-probe marker patches (sorry, no link at hand, can be found in latest LTTng, maybe also already in -mm). Those patches introduce a marker probe trampoline like this: void marker_probe_cb(const struct marker *mdata, void *call_private, const char *fmt, ...) { va_list args; char ptype; /* * rcu_read_lock does two things : disabling preemption to make sure the * teardown of the callbacks can be done correctly when they are in * modules and they insure RCU read coherency. */ rcu_read_lock(); preempt_disable(); ... Can we do multi-probe with pure preempt_disable/enable protection? I guess it's fine with classic RCU, but what about preemptible RCU? Any suggestion appreciated! Jan PS: You will run into this issue if you try to marry latest -rt with latest LTTng. Straightforward workaround is to comment-out any RCU trace_mark occurrences. -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html