On Wed, Apr 19, 2017 at 05:40:40PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 08:08:09AM -0700, Paul E. McKenney wrote:
> > And even that would not be completely sufficient. After all, the state
> > in the leaf rcu_node structure will be out of date during grace-period
> >
On Wed, Apr 19, 2017 at 05:40:40PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 08:08:09AM -0700, Paul E. McKenney wrote:
> > And even that would not be completely sufficient. After all, the state
> > in the leaf rcu_node structure will be out of date during grace-period
> >
On Wed, Apr 19, 2017 at 08:08:09AM -0700, Paul E. McKenney wrote:
> And even that would not be completely sufficient. After all, the state
> in the leaf rcu_node structure will be out of date during grace-period
> initialization and cleanup. So to -completely- synchronize state for
> the
On Wed, Apr 19, 2017 at 08:08:09AM -0700, Paul E. McKenney wrote:
> And even that would not be completely sufficient. After all, the state
> in the leaf rcu_node structure will be out of date during grace-period
> initialization and cleanup. So to -completely- synchronize state for
> the
On Wed, Apr 19, 2017 at 03:48:35PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 03:22:26PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
> >
> > > I believe that you are missing the fact that RCU grace-period
> > > initialization and
On Wed, Apr 19, 2017 at 03:48:35PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 03:22:26PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
> >
> > > I believe that you are missing the fact that RCU grace-period
> > > initialization and
On Wed, Apr 19, 2017 at 03:22:26PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
>
> > I believe that you are missing the fact that RCU grace-period
> > initialization and cleanup walks through the rcu_node tree breadth
> > first, using
On Wed, Apr 19, 2017 at 03:22:26PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
>
> > I believe that you are missing the fact that RCU grace-period
> > initialization and cleanup walks through the rcu_node tree breadth
> > first, using
On Wed, Apr 19, 2017 at 03:22:26PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
>
> > I believe that you are missing the fact that RCU grace-period
> > initialization and cleanup walks through the rcu_node tree breadth
> > first, using
On Wed, Apr 19, 2017 at 03:22:26PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
>
> > I believe that you are missing the fact that RCU grace-period
> > initialization and cleanup walks through the rcu_node tree breadth
> > first, using
On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
> I believe that you are missing the fact that RCU grace-period
> initialization and cleanup walks through the rcu_node tree breadth
> first, using rcu_for_each_node_breadth_first().
Indeed. That is the part I completely missed.
On Thu, Apr 13, 2017 at 11:42:32AM -0700, Paul E. McKenney wrote:
> I believe that you are missing the fact that RCU grace-period
> initialization and cleanup walks through the rcu_node tree breadth
> first, using rcu_for_each_node_breadth_first().
Indeed. That is the part I completely missed.
On Thu, Apr 13, 2017 at 08:29:39PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
>
> > > And I have vague memories of it actually causing lock contention, but
> > > I've
On Thu, Apr 13, 2017 at 08:29:39PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
>
> > > And I have vague memories of it actually causing lock contention, but
> > > I've
On Thu, Apr 13, 2017 at 08:23:09PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 11:19:26AM -0700, Paul E. McKenney wrote:
>
> > First get me some system-level data showing that the current layout is
> > causing a real problem. RCU's fastpath code doesn't come anywhere near
> > the
On Thu, Apr 13, 2017 at 08:23:09PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 11:19:26AM -0700, Paul E. McKenney wrote:
>
> > First get me some system-level data showing that the current layout is
> > causing a real problem. RCU's fastpath code doesn't come anywhere near
> > the
On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> > And I have vague memories of it actually causing lock contention, but
> > I've forgotten how that worked.
>
> That is a new one on me. I can easily see how not
On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> > And I have vague memories of it actually causing lock contention, but
> > I've forgotten how that worked.
>
> That is a new one on me. I can easily see how not
On Thu, Apr 13, 2017 at 11:19:26AM -0700, Paul E. McKenney wrote:
> First get me some system-level data showing that the current layout is
> causing a real problem. RCU's fastpath code doesn't come anywhere near
> the rcu_node tree, so in the absence of such data, I of course remain
> quite
On Thu, Apr 13, 2017 at 11:19:26AM -0700, Paul E. McKenney wrote:
> First get me some system-level data showing that the current layout is
> causing a real problem. RCU's fastpath code doesn't come anywhere near
> the rcu_node tree, so in the absence of such data, I of course remain
> quite
On Thu, Apr 13, 2017 at 07:46:31PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > > > > To avoid
On Thu, Apr 13, 2017 at 07:46:31PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > > > > To avoid
On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > > > To avoid people tuning huge machines having to wait for me to give
> > > > > them an
On Thu, Apr 13, 2017 at 10:31:00AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > > > To avoid people tuning huge machines having to wait for me to give
> > > > > them an
On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > > To avoid people tuning huge machines having to wait for me to give
> > > > them an answer as to why they are suffering lock contention after
> > > > cranking
On Thu, Apr 13, 2017 at 07:04:34PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > > To avoid people tuning huge machines having to wait for me to give
> > > > them an answer as to why they are suffering lock contention after
> > > > cranking
On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > To avoid people tuning huge machines having to wait for me to give
> > > them an answer as to why they are suffering lock contention after
> > > cranking up the value of RCU_FANOUT_LEAF.
So is there a good reason to increase
On Thu, Apr 13, 2017 at 09:55:16AM -0700, Paul E. McKenney wrote:
> > > To avoid people tuning huge machines having to wait for me to give
> > > them an answer as to why they are suffering lock contention after
> > > cranking up the value of RCU_FANOUT_LEAF.
So is there a good reason to increase
On Thu, Apr 13, 2017 at 06:19:48PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 09:03:33AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 13, 2017 at 11:15:35AM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> > > > If you set
On Thu, Apr 13, 2017 at 06:19:48PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 09:03:33AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 13, 2017 at 11:15:35AM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> > > > If you set
On Thu, Apr 13, 2017 at 09:03:33AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 13, 2017 at 11:15:35AM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> > > If you set RCU_FANOUT_LEAF too high, you can get lock contention
> > > on the leaf
On Thu, Apr 13, 2017 at 09:03:33AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 13, 2017 at 11:15:35AM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> > > If you set RCU_FANOUT_LEAF too high, you can get lock contention
> > > on the leaf
On Thu, Apr 13, 2017 at 11:15:35AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> > If you set RCU_FANOUT_LEAF too high, you can get lock contention
> > on the leaf rcu_node, and you should boot with the skew_tick kernel
> > parameter set in
On Thu, Apr 13, 2017 at 11:15:35AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> > If you set RCU_FANOUT_LEAF too high, you can get lock contention
> > on the leaf rcu_node, and you should boot with the skew_tick kernel
> > parameter set in
On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> If you set RCU_FANOUT_LEAF too high, you can get lock contention
> on the leaf rcu_node, and you should boot with the skew_tick kernel
> parameter set in order to avoid this lock contention. This commit
> therefore upgrades the
On Wed, Apr 12, 2017 at 09:55:40AM -0700, Paul E. McKenney wrote:
> If you set RCU_FANOUT_LEAF too high, you can get lock contention
> on the leaf rcu_node, and you should boot with the skew_tick kernel
> parameter set in order to avoid this lock contention. This commit
> therefore upgrades the
If you set RCU_FANOUT_LEAF too high, you can get lock contention
on the leaf rcu_node, and you should boot with the skew_tick kernel
parameter set in order to avoid this lock contention. This commit
therefore upgrades the RCU_FANOUT_LEAF help text to explicitly state
this.
Signed-off-by: Paul E.
If you set RCU_FANOUT_LEAF too high, you can get lock contention
on the leaf rcu_node, and you should boot with the skew_tick kernel
parameter set in order to avoid this lock contention. This commit
therefore upgrades the RCU_FANOUT_LEAF help text to explicitly state
this.
Signed-off-by: Paul E.
38 matches
Mail list logo