Re: [PATCH RFC 0/7] rcu: v2 Inlinable preemptible rcu_read_lock()and rcu_read_unlock()

[Paul E. McKenney]

On Sat, Apr 14, 2012 at 10:25:04AM -0700, Paul E. McKenney wrote:
> On Sat, Apr 14, 2012 at 10:08:54AM -0700, Linus Torvalds wrote:
> > On Sat, Apr 14, 2012 at 9:58 AM, Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > I'll see if it boots and what it does to my profiles and
> > > microbenchmark, though.
> > 
> > Ok, I can't see any performance difference in the numbers - my
> > benchmark noise is *much* bigger than anything this would show.
> 
> Might still be worthwhile on embedded CPUs that don't optimize
> function calls as thoroughly as does x86, maybe?
> 
> > The profile looks fine, and obviously __rcu_read_lock() is entirely
> > gone. The top user (avc_has_perm_flags()) looks fine. I note that you
> > might want to look at the placement of the percpu data - I think it
> > probably makes sense to put the RCU data close to 'current' etc to get
> > as much cacheline sharing as possible, and it doesn't seem to be right
> > now, but it looks reasonable.
> 
> Is there somewhere in non-architecture-specific code that would be a
> good place to put this?  Or is the DEFINE_PER_CPU() for current_task
> moving from arch/x86 to core code?
> 
> > But on the whole, I can't claim that it looks noticeable ;*(
> 
> Well, then, I guess I don't feel quite so bad about having prioritized
> this so low for so long.  ;-)

One other thing -- may I add your Tested-by to the series?

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/