| Message ID | 20150316173154.537b80ee@gandalf.local.home (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 16 Mar 2015, Steven Rostedt wrote: > It has come to my attention that this_cpu_read/write are horrible on > architectures other than x86. Worse yet, they actually disable > preemption or interrupts! This caused some unexpected tracing results > on ARM. Well its just been 7 years or so. Took a long time it seems. These would need to be implemented on the architectures to have comparable performance. > I may go and remove all this_cpu_read,write() calls from my code > because of this. You could do that with __this_cpo_* but not this_cpu_*(). Doing it to this_cpu_* would make the operations no longer per cpu atomic. If they do not need per cpu atomicity then you could have used __this_cpu_* instead. And __this_cpu_* do not disable preemption or interrupts. So please do not send patches based on gut reactions. NAK
On Tue, 17 Mar 2015 00:56:51 -0500 (CDT) Christoph Lameter <cl@linux.com> wrote: > On Mon, 16 Mar 2015, Steven Rostedt wrote: > > > It has come to my attention that this_cpu_read/write are horrible on > > architectures other than x86. Worse yet, they actually disable > > preemption or interrupts! This caused some unexpected tracing results > > on ARM. > > Well its just been 7 years or so. Took a long time it seems. The code that I added was not 7 years old. And not all people send me reports like this. > > These would need to be implemented on the architectures to > have comparable performance. > > > I may go and remove all this_cpu_read,write() calls from my code > > because of this. > > You could do that with __this_cpo_* but not this_cpu_*(). Doing > it to this_cpu_* would make the operations no longer per cpu atomic. If > they do not need per cpu atomicity then you could have used __this_cpu_* > instead. And __this_cpu_* do not disable preemption or interrupts. I do not need it to be atomic. > > So please do not send patches based on gut reactions. What else would you like me to do? It was an RFC, and it worked. > > NAK For this particular patch, I may override the NAK as I do not see a downside for it. Why should x86 get an advantage at the expense of ARM? -- Steve
On Tue, 17 Mar 2015 08:13:41 -0400 Steven Rostedt <rostedt@goodmis.org> wrote: > > > I may go and remove all this_cpu_read,write() calls from my code > > > because of this. > > > > You could do that with __this_cpo_* but not this_cpu_*(). Doing > > it to this_cpu_* would make the operations no longer per cpu atomic. If > > they do not need per cpu atomicity then you could have used __this_cpu_* > > instead. And __this_cpu_* do not disable preemption or interrupts. > > I do not need it to be atomic. I test this out with __this_cpu_* versions and see if that solves it too. If it does, I'll use that version instead. Thanks, -- Steve
On Tue, 17 Mar 2015, Steven Rostedt wrote: > I test this out with __this_cpu_* versions and see if that solves it > too. If it does, I'll use that version instead. Yeah that may be best. Sorry for the delay. Stuck at yet another conference.
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 5040d44fe5a3..be33c6093ca5 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -2679,7 +2679,11 @@ static DEFINE_PER_CPU(unsigned int, current_context); static __always_inline int trace_recursive_lock(void) { - unsigned int val = this_cpu_read(current_context); + /* + * We can not use this_cpu_read() and this_cpu_write() because + * the generic versions call preempt_disable() + */ + unsigned int val = *this_cpu_ptr(¤t_context); int bit; if (in_interrupt()) { @@ -2696,18 +2700,18 @@ static __always_inline int trace_recursive_lock(void) return 1; val |= (1 << bit); - this_cpu_write(current_context, val); + *this_cpu_ptr(¤t_context) = val; return 0; } static __always_inline void trace_recursive_unlock(void) { - unsigned int val = this_cpu_read(current_context); + unsigned int val = *this_cpu_ptr(¤t_context); val--; val &= this_cpu_read(current_context); - this_cpu_write(current_context, val); + *this_cpu_ptr(¤t_context) = val; } #else
It has come to my attention that this_cpu_read/write are horrible on architectures other than x86. Worse yet, they actually disable preemption or interrupts! This caused some unexpected tracing results on ARM. 101.356868: preempt_count_add <-ring_buffer_lock_reserve 101.356870: preempt_count_sub <-ring_buffer_lock_reserve The ring_buffer_lock_reserve has recursion protection that requires accessing a per cpu variable. But since preempt_disable() is traced, it too got traced while accessing the variable that is suppose to prevent recursion like this. The generic version of this_cpu_read() and write() are: #define _this_cpu_generic_read(pcp) \ ({ typeof(pcp) ret__; \ preempt_disable(); \ ret__ = *this_cpu_ptr(&(pcp)); \ preempt_enable(); \ ret__; \ }) #define _this_cpu_generic_to_op(pcp, val, op) \ do { \ unsigned long flags; \ raw_local_irq_save(flags); \ *__this_cpu_ptr(&(pcp)) op val; \ raw_local_irq_restore(flags); \ } while (0) Which is unacceptable for locations that know they are within preempt disabled or interrupt disabled locations. I may go and remove all this_cpu_read,write() calls from my code because of this. Cc: stable@vger.kernel.org Cc: Christoph Lameter <cl@linux.com> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> ---