Messages in this thread | | | Date | Wed, 8 Aug 2018 09:03:50 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage |
| |
On Wed, Aug 08, 2018 at 11:27:05AM -0400, Steven Rostedt wrote: > On Wed, 8 Aug 2018 07:42:00 -0700 > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > > > There's also a local_inc() if you are using per cpu pointers, that is > > > suppose to guarantee atomicity for single cpu operations. That's what > > > the ftrace ring buffer uses. > > > > Good point, that becomes atomic_long_inc() or equivalent on most > > architectures, but an incl instruction (not locked) on x86. So updating > > my earlier still-untested thought: > > > > int __srcu_read_lock_nmi(struct srcu_struct *sp) /* UNTESTED. */ > > { > > int idx; > > > > idx = READ_ONCE(sp->srcu_idx) & 0x1; > > local_inc(&sp->sda->srcu_lock_count[idx]); > > smp_mb__after_atomic(); /* B */ /* Avoid leaking critical section. */ > > return idx; > > } > > > > void __srcu_read_unlock_nmi(struct srcu_struct *sp, int idx) > > { > > smp_mb__before_atomic(); /* C */ /* Avoid leaking critical section. */ > > local_inc(&sp->sda->srcu_unlock_count[idx]); > > } > > > > Would that work, or is there a better way to handle this? > > This would work much better than using the atomic ops, and I think it > would be doable.
OK, here is hoping!
> I may need to revert the srcu for trace_*_rcidle() for now, as I want > most of the other changes in this merge window, and it's getting too > late to do it with these updates.
Agreed, especially since I normally freeze for the next merge window shortly after -rc5. ;-)
Thanx, Paul
| |