On Tue, May 28, 2013 at 12:07:42PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > rcu: Fix comparison sense in rcu_needs_cpu()
> > > >
> > > > Commit c0f4dfd4f
* Paul E. McKenney wrote:
> On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > rcu: Fix comparison sense in rcu_needs_cpu()
> > >
> > > Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
> > > callbacks) introduced a
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
rcu: Fix comparison sense in rcu_needs_cpu()
Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of
On Tue, May 28, 2013 at 12:07:42PM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
rcu: Fix comparison sense in rcu_needs_cpu()
On Tue, May 21, 2013 at 11:45:31AM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 06:22:10AM -0700, Paul E. McKenney wrote:
> > > But somehow I imagined making a CPU part of the GP would be easier than
> > > taking
> > > it out. After all, taking it out is dangerous and careful work, one
On Thu, May 16, 2013 at 06:22:10AM -0700, Paul E. McKenney wrote:
> > But somehow I imagined making a CPU part of the GP would be easier than
> > taking
> > it out. After all, taking it out is dangerous and careful work, one is not
> > to
> > accidentally execute a callback or otherwise end a GP
On Thu, May 16, 2013 at 06:22:10AM -0700, Paul E. McKenney wrote:
But somehow I imagined making a CPU part of the GP would be easier than
taking
it out. After all, taking it out is dangerous and careful work, one is not
to
accidentally execute a callback or otherwise end a GP before
On Tue, May 21, 2013 at 11:45:31AM +0200, Peter Zijlstra wrote:
On Thu, May 16, 2013 at 06:22:10AM -0700, Paul E. McKenney wrote:
But somehow I imagined making a CPU part of the GP would be easier than
taking
it out. After all, taking it out is dangerous and careful work, one is
not
On Thu, May 16, 2013 at 11:45:19AM +0200, Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 10:31:42AM -0700, Paul E. McKenney wrote:
> > On Wed, May 15, 2013 at 11:02:34AM +0200, Peter Zijlstra wrote:
>
> > > Earlier you said that improving EQS behaviour was expensive in that it
> > > would
On Thu, May 16, 2013 at 11:37:40AM +0200, Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 09:37:00AM -0700, Paul E. McKenney wrote:
> > The need is to detect that an idle CPU is idle without making it do
> > anything. To do otherwise would kill battery lifetime and introduce
> > OS jitter.
>
>
On Wed, May 15, 2013 at 10:31:42AM -0700, Paul E. McKenney wrote:
> On Wed, May 15, 2013 at 11:02:34AM +0200, Peter Zijlstra wrote:
> > Earlier you said that improving EQS behaviour was expensive in that it
> > would require taking (global) locks or somesuch.
> >
> > Would it not be possible to
On Wed, May 15, 2013 at 09:37:00AM -0700, Paul E. McKenney wrote:
> The need is to detect that an idle CPU is idle without making it do
> anything. To do otherwise would kill battery lifetime and introduce
> OS jitter.
Not anything isn't leaving us much room to wriggle, we could maybe try and do
On Wed, May 15, 2013 at 09:37:00AM -0700, Paul E. McKenney wrote:
The need is to detect that an idle CPU is idle without making it do
anything. To do otherwise would kill battery lifetime and introduce
OS jitter.
Not anything isn't leaving us much room to wriggle, we could maybe try and do a
On Wed, May 15, 2013 at 10:31:42AM -0700, Paul E. McKenney wrote:
On Wed, May 15, 2013 at 11:02:34AM +0200, Peter Zijlstra wrote:
Earlier you said that improving EQS behaviour was expensive in that it
would require taking (global) locks or somesuch.
Would it not be possible to have the
On Thu, May 16, 2013 at 11:37:40AM +0200, Peter Zijlstra wrote:
On Wed, May 15, 2013 at 09:37:00AM -0700, Paul E. McKenney wrote:
The need is to detect that an idle CPU is idle without making it do
anything. To do otherwise would kill battery lifetime and introduce
OS jitter.
Not
On Thu, May 16, 2013 at 11:45:19AM +0200, Peter Zijlstra wrote:
On Wed, May 15, 2013 at 10:31:42AM -0700, Paul E. McKenney wrote:
On Wed, May 15, 2013 at 11:02:34AM +0200, Peter Zijlstra wrote:
Earlier you said that improving EQS behaviour was expensive in that it
would require taking
On Wed, May 15, 2013 at 11:02:34AM +0200, Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 10:56:39AM +0200, Peter Zijlstra wrote:
> > On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > > > > In theory, yes.
On Wed, May 15, 2013 at 10:56:39AM +0200, Peter Zijlstra wrote:
> On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
> > On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > > > In theory, yes. In practice, this requires lots of lock acquisitions
> > > > and releases
On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > rcu: Fix comparison sense in rcu_needs_cpu()
> >
> > Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
> > callbacks) introduced a bug that can result in excessively long grace
* Paul E. McKenney wrote:
> rcu: Fix comparison sense in rcu_needs_cpu()
>
> Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
> callbacks) introduced a bug that can result in excessively long grace
> periods. This bug reverse the senes of the "if" statement checking
> for
On Wed, May 15, 2013 at 10:56:39AM +0200, Peter Zijlstra wrote:
> On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
> > On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > > > In theory, yes. In practice, this requires lots of lock acquisitions
> > > > and releases
On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
> On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > > In theory, yes. In practice, this requires lots of lock acquisitions
> > > and releases on large systems, including some global locks. The weight
> > > could
On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
In theory, yes. In practice, this requires lots of lock acquisitions
and releases on large systems, including some global locks. The weight
could be
On Wed, May 15, 2013 at 10:56:39AM +0200, Peter Zijlstra wrote:
On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
In theory, yes. In practice, this requires lots of lock acquisitions
and releases on large
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
rcu: Fix comparison sense in rcu_needs_cpu()
Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
callbacks) introduced a bug that can result in excessively long grace
periods. This bug reverse the senes of the if
On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
rcu: Fix comparison sense in rcu_needs_cpu()
Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
callbacks) introduced a bug that can result in
On Wed, May 15, 2013 at 10:56:39AM +0200, Peter Zijlstra wrote:
On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
In theory, yes. In practice, this requires lots of lock acquisitions
and releases on large
On Wed, May 15, 2013 at 11:02:34AM +0200, Peter Zijlstra wrote:
On Wed, May 15, 2013 at 10:56:39AM +0200, Peter Zijlstra wrote:
On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
In theory, yes. In practice,
On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > In theory, yes. In practice, this requires lots of lock acquisitions
> > and releases on large systems, including some global locks. The weight
> > could be reduced, but...
> >
> > What I would like to do instead would be to
> In theory, yes. In practice, this requires lots of lock acquisitions
> and releases on large systems, including some global locks. The weight
> could be reduced, but...
>
> What I would like to do instead would be to specify expedited grace
> periods during boot.
But why, surely going idle
On Tue, May 14, 2013 at 02:20:49PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 13, 2013 at 03:09:43PM -0700, Paul E. McKenney wrote:
> > > How are those CPUs going idle without first telling RCU that they're
> > > quiesced? Seems like, during boot at least, you want RCU to use its
> > >
On Sat, Apr 13, 2013 at 03:09:43PM -0700, Paul E. McKenney wrote:
> > How are those CPUs going idle without first telling RCU that they're
> > quiesced? Seems like, during boot at least, you want RCU to use its
> > idle==quiesced logic to proactively note continuously-quiescent states.
> >
On Sat, Apr 13, 2013 at 03:09:43PM -0700, Paul E. McKenney wrote:
How are those CPUs going idle without first telling RCU that they're
quiesced? Seems like, during boot at least, you want RCU to use its
idle==quiesced logic to proactively note continuously-quiescent states.
Ideally, you
On Tue, May 14, 2013 at 02:20:49PM +0200, Peter Zijlstra wrote:
On Sat, Apr 13, 2013 at 03:09:43PM -0700, Paul E. McKenney wrote:
How are those CPUs going idle without first telling RCU that they're
quiesced? Seems like, during boot at least, you want RCU to use its
idle==quiesced logic
In theory, yes. In practice, this requires lots of lock acquisitions
and releases on large systems, including some global locks. The weight
could be reduced, but...
What I would like to do instead would be to specify expedited grace
periods during boot.
But why, surely going idle without
On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
In theory, yes. In practice, this requires lots of lock acquisitions
and releases on large systems, including some global locks. The weight
could be reduced, but...
What I would like to do instead would be to specify
On Mon, Apr 15, 2013 at 12:03:54PM +1000, Paul Mackerras wrote:
> On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
> > On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
> > > On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
> > > > From: "Paul E.
On Mon, Apr 15, 2013 at 12:03:54PM +1000, Paul Mackerras wrote:
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
> On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
> > On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > Systems with HZ=100 can have slow bootup times due
On Sat, Apr 13, 2013 at 03:09:43PM -0700, Paul E. McKenney wrote:
> On Sat, Apr 13, 2013 at 12:53:36PM -0700, Josh Triplett wrote:
> > On Sat, Apr 13, 2013 at 12:34:25PM -0700, Paul E. McKenney wrote:
> > > On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
> > > > On Fri, Apr 12, 2013
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Systems with HZ=100 can have slow bootup
On Sat, Apr 13, 2013 at 03:09:43PM -0700, Paul E. McKenney wrote:
On Sat, Apr 13, 2013 at 12:53:36PM -0700, Josh Triplett wrote:
On Sat, Apr 13, 2013 at 12:34:25PM -0700, Paul E. McKenney wrote:
On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at
On Sat, Apr 13, 2013 at 12:53:36PM -0700, Josh Triplett wrote:
> On Sat, Apr 13, 2013 at 12:34:25PM -0700, Paul E. McKenney wrote:
> > On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
> > > On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Apr 12, 2013
On Sat, Apr 13, 2013 at 12:34:25PM -0700, Paul E. McKenney wrote:
> On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
> > On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
> > > On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
> > > > On Fri, Apr 12, 2013
On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
> On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
> > On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
> > > On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
> > > > From: "Paul E.
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
> On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
> > On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > Systems with HZ=100 can have slow bootup times due
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
> On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > Systems with HZ=100 can have slow bootup times due to the default
> > three-jiffy delays between quiescent-state forcing
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Systems with HZ=100 can have slow bootup times due to the default
three-jiffy delays between quiescent-state
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Systems with HZ=100 can have slow bootup
On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney
On Sat, Apr 13, 2013 at 12:34:25PM -0700, Paul E. McKenney wrote:
On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
On Fri, Apr 12, 2013 at 04:54:02PM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at
On Sat, Apr 13, 2013 at 12:53:36PM -0700, Josh Triplett wrote:
On Sat, Apr 13, 2013 at 12:34:25PM -0700, Paul E. McKenney wrote:
On Sat, Apr 13, 2013 at 11:18:00AM -0700, Josh Triplett wrote:
On Fri, Apr 12, 2013 at 11:38:04PM -0700, Paul E. McKenney wrote:
On Fri, Apr 12, 2013 at
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> Systems with HZ=100 can have slow bootup times due to the default
> three-jiffy delays between quiescent-state forcing attempts. This
> commit therefore auto-tunes the RCU_JIFFIES_TILL_FORCE_QS
From: "Paul E. McKenney"
Systems with HZ=100 can have slow bootup times due to the default
three-jiffy delays between quiescent-state forcing attempts. This
commit therefore auto-tunes the RCU_JIFFIES_TILL_FORCE_QS value based
on the value of HZ. However, this would break very large systems
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Systems with HZ=100 can have slow bootup times due to the default
three-jiffy delays between quiescent-state forcing attempts. This
commit therefore auto-tunes the RCU_JIFFIES_TILL_FORCE_QS value based
on the value of HZ. However, this would
On Fri, Apr 12, 2013 at 04:19:13PM -0700, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Systems with HZ=100 can have slow bootup times due to the default
three-jiffy delays between quiescent-state forcing attempts. This
commit therefore auto-tunes the
56 matches
Mail list logo
