Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-05-28 Thread Rusty Russell
Peter Zijlstra writes: > On Thu, May 28, 2015 at 11:37:17AM +0930, Rusty Russell wrote: >> That's rcu_read_lock_sched_held, not rcu_held_lock_sched_held(). >> >> Also, your unlikely is weird and backwards. >> >> I changed it as below, and folded. It's in modules-next. >> >> I'm now going to do

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-05-28 Thread Peter Zijlstra
On Thu, May 28, 2015 at 11:37:17AM +0930, Rusty Russell wrote: > That's rcu_read_lock_sched_held, not rcu_held_lock_sched_held(). > > Also, your unlikely is weird and backwards. > > I changed it as below, and folded. It's in modules-next. > > I'm now going to do some *actual* testing, and I'll

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-05-27 Thread Rusty Russell
Peter Zijlstra writes: > On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote: Hmm, this blows up: > +static void module_assert_mutex_or_preempt(void) > +{ > +#ifdef CONFIG_LOCKDEP > + if (!unlikely(debug_locks)) > + return; > + > + WARN_ON(!rcu_held_lock_sched_held(

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-04-15 Thread Peter Zijlstra
On Wed, Apr 15, 2015 at 02:11:37PM +0930, Rusty Russell wrote: > Peter Zijlstra writes: > > On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote: > > > >> I was tempted to sneak in those module rcu fixes for 4.1, but seeing > >> Ingo's comments I'll wait for 4.2. > > > > I can get you a n

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-04-14 Thread Rusty Russell
Peter Zijlstra writes: > On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote: > >> I was tempted to sneak in those module rcu fixes for 4.1, but seeing >> Ingo's comments I'll wait for 4.2. > > I can get you a new version of that if you want. See below. The fixups > are unmodified of the

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-04-13 Thread Peter Zijlstra
On Tue, Apr 14, 2015 at 12:27:05PM +0930, Rusty Russell wrote: > I was tempted to sneak in those module rcu fixes for 4.1, but seeing > Ingo's comments I'll wait for 4.2. I can get you a new version of that if you want. See below. The fixups are unmodified of the posting (patches 2,3). --- Subje

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-04-13 Thread Rusty Russell
Peter Zijlstra writes: > This series is aimed at making __module_address() go fast(er). > > The reason for doing so is that most stack unwinders use kernel_text_address() > to validate each frame. Perf and ftrace (can) end up doing a lot of stack > traces from performance sensitive code. > > On th

Re: [PATCH v5 00/10] latched RB-trees and __module_address()

2015-04-13 Thread Ingo Molnar
* Peter Zijlstra wrote: > This series is aimed at making __module_address() go fast(er). > > The reason for doing so is that most stack unwinders use kernel_text_address() > to validate each frame. Perf and ftrace (can) end up doing a lot of stack > traces from performance sensitive code. > >

[PATCH v5 00/10] latched RB-trees and __module_address()

2015-04-13 Thread Peter Zijlstra
This series is aimed at making __module_address() go fast(er). The reason for doing so is that most stack unwinders use kernel_text_address() to validate each frame. Perf and ftrace (can) end up doing a lot of stack traces from performance sensitive code. On the way there it: - annotates and sa