Re: question about RCU dynticks_nesting

[Paul E. McKenney]

On Tue, May 05, 2015 at 05:09:23PM -0400, Rik van Riel wrote:
> On 05/05/2015 02:35 PM, Paul E. McKenney wrote:
> > On Tue, May 05, 2015 at 03:00:26PM +0200, Peter Zijlstra wrote:
> >> On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote:
> >>> On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
> >>>> On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
> >>>>> But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt
> >>>>> counter in production kernels.  Even if there was, we have to sample this
> >>>>> on other CPUs, so the overhead of preempt_disable() and preempt_enable()
> >>>>> would be where kernel entry/exit is, so I expect that this would be a
> >>>>> net loss in overall performance.
> >>>>
> >>>> We unconditionally have the preempt_count, its just not used much for
> >>>> PREEMPT_COUNT=n kernels.
> >>>
> >>> We have the field, you mean?  I might be missing something, but it still
> >>> appears to me thta preempt_disable() does nothing for PREEMPT=n kernels.
> >>> So what am I missing?
> >>
> >> There's another layer of accessors that can in fact manipulate the
> >> preempt_count even for !PREEMPT_COUNT kernels. They are currently used
> >> by things like pagefault_disable().
> > 
> > OK, fair enough.
> > 
> > I am going to focus first on getting rid of (or at least greatly reducing)
> > RCU's interrupt disabling on the user-kernel entry/exit paths, since
> > that seems to be the biggest cost.
> 
> Interrupts are already disabled on kernel-user and kernel-guest
> switches.  Paolo and I have patches to move a bunch of the calls
> to user_enter, user_exit, guest_enter, and guest_exit to places
> where interrupts are already disabled, so we do not need to
> disable them again.
> 
> With those in place, the vtime calculations are the largest
> CPU user. I am working on those.

OK, so I should stop worrying about making rcu_user_enter() and
rcu_user_exit() operate with interrupts disabled, and instead think about
the overhead of the operations themselves.  Probably starting from Mike
Galbraith's profile (thank you!) unless Rik has some reason to believe
that it is nonrepresentative.

							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/