On Thu, Jul 03, 2014 at 03:12:17PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 10:55:01AM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 02, 2014 at 07:26:00PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> > > > As were others, not
On Thu, Jul 03, 2014 at 11:50:09AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 10:55:01AM -0700, Paul E. McKenney wrote:
> > Name me one thing that isn't annoying. ;-)
>
> A cold beverage on a warm day :-)
Fair point... Not clear how to work that into the RCU implementation,
though.
On Wed, Jul 02, 2014 at 10:55:01AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 02, 2014 at 07:26:00PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> > > As were others, not that long ago. Today is the first hint that I got
> > > that you feel
On Wed, Jul 02, 2014 at 01:29:38PM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/02/2014 01:26 PM, Peter Zijlstra wrote:
> > On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> >> As were others, not that long ago. Today is the first hint t
On Wed, Jul 02, 2014 at 10:55:01AM -0700, Paul E. McKenney wrote:
> Name me one thing that isn't annoying. ;-)
A cold beverage on a warm day :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote:
> On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote:
> > On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote:
>
> > > NO_HZ_FULL is a property of a set of CPUs. isolcpus is supposed to go
> > > away as being a red
On Fri, Jul 04, 2014 at 08:01:34AM +0200, Mike Galbraith wrote:
> On Thu, 2014-07-03 at 22:05 -0700, Paul E. McKenney wrote:
> > On Fri, Jul 04, 2014 at 05:23:56AM +0200, Mike Galbraith wrote:
>
> > > Turn it on and don't worry about it is exactly what distros want the
> > > obscure feature with
On Thu, 2014-07-03 at 22:05 -0700, Paul E. McKenney wrote:
> On Fri, Jul 04, 2014 at 05:23:56AM +0200, Mike Galbraith wrote:
> > Turn it on and don't worry about it is exactly what distros want the
> > obscure feature with very few users to be. Last time I did a drive-by,
> > my boxen said I sho
On Fri, Jul 04, 2014 at 05:23:56AM +0200, Mike Galbraith wrote:
> On Thu, 2014-07-03 at 09:29 -0700, Paul E. McKenney wrote:
> > On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote:
> > > On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote:
> > > > On Thu, Jul 03, 2014 at 05:31:1
On Thu, 2014-07-03 at 09:29 -0700, Paul E. McKenney wrote:
> On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote:
> > On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote:
> > > On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote:
> >
> > > > NO_HZ_FULL is a property o
On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote:
> On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote:
> > On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote:
>
> > > NO_HZ_FULL is a property of a set of CPUs. isolcpus is supposed to go
> > > away as being a red
On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote:
> On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote:
> > NO_HZ_FULL is a property of a set of CPUs. isolcpus is supposed to go
> > away as being a redundant interface to manage a single property of a set
> > of CPUs, but it'
On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote:
> On Wed, 2014-07-02 at 10:08 -0700, Paul E. McKenney wrote:
> > On Wed, Jul 02, 2014 at 06:04:12PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 02, 2014 at 08:39:15AM -0700, Paul E. McKenney wrote:
> > > > On Wed, Jul 02, 2014 at 0
On Wed, 2014-07-02 at 10:08 -0700, Paul E. McKenney wrote:
> On Wed, Jul 02, 2014 at 06:04:12PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 02, 2014 at 08:39:15AM -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 02, 2014 at 02:34:12PM +0200, Peter Zijlstra wrote:
> > > > On Fri, Jun 27, 2014 at 0
On Wed, Jul 02, 2014 at 09:55:56AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 02, 2014 at 09:46:19AM -0400, Rik van Riel wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 07/02/2014 08:34 AM, Peter Zijlstra wrote:
> > > On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKe
On Wed, Jul 02, 2014 at 01:29:38PM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/02/2014 01:26 PM, Peter Zijlstra wrote:
> > On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> >> As were others, not that long ago. Today is the first hint t
On Wed, Jul 02, 2014 at 07:26:00PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> > As were others, not that long ago. Today is the first hint that I got
> > that you feel otherwise. But it does look like the softirq approach to
> > callback pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 01:26 PM, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
>> As were others, not that long ago. Today is the first hint that
>> I got that you feel otherwise. But it does look like the softirq
>
On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> As were others, not that long ago. Today is the first hint that I got
> that you feel otherwise. But it does look like the softirq approach to
> callback processing needs to stick around for awhile longer. Nice to
> hear that so
On Wed, Jul 02, 2014 at 06:04:12PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 08:39:15AM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 02, 2014 at 02:34:12PM +0200, Peter Zijlstra wrote:
> > > On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKenney wrote:
> > > > An 80-CPU system wi
On Wed, Jul 02, 2014 at 09:46:19AM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/02/2014 08:34 AM, Peter Zijlstra wrote:
> > On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKenney wrote:
> >> An 80-CPU system with a context-switch-heavy workload can req
On Wed, Jul 02, 2014 at 08:39:15AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 02, 2014 at 02:34:12PM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKenney wrote:
> > > An 80-CPU system with a context-switch-heavy workload can require so
> > > many NOCB kthrea
On Wed, Jul 02, 2014 at 02:34:12PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKenney wrote:
> > An 80-CPU system with a context-switch-heavy workload can require so
> > many NOCB kthread wakeups that the RCU grace-period kthreads spend several
> > tens of per
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 08:34 AM, Peter Zijlstra wrote:
> On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKenney wrote:
>> An 80-CPU system with a context-switch-heavy workload can require
>> so many NOCB kthread wakeups that the RCU grace-period kthreads
>>
On Fri, Jun 27, 2014 at 07:20:38AM -0700, Paul E. McKenney wrote:
> An 80-CPU system with a context-switch-heavy workload can require so
> many NOCB kthread wakeups that the RCU grace-period kthreads spend several
> tens of percent of a CPU just awakening things. This clearly will not
> scale well
edhat.com, s...@mit.edu
> > Sent: Friday, June 27, 2014 11:01:27 AM
> > Subject: Re: [PATCH RFC tip/core/rcu] Parallelize and economize NOCB
> > kthread wakeups
> >
> > - Original Message -
> > > From: "Paul E. McKenney"
> > > To:
gt; o...@redhat.com, s...@mit.edu
> > Sent: Friday, June 27, 2014 10:20:38 AM
> > Subject: [PATCH RFC tip/core/rcu] Parallelize and economize NOCB kthread
> > wakeups
> >
> > An 80-CPU system with a context-switch-heavy workload can require so
> > many NOCB kthread w
om,
> t...@linutronix.de, pet...@infradead.org,
> rost...@goodmis.org, dhowe...@redhat.com, eduma...@google.com,
> dvh...@linux.intel.com, fweis...@gmail.com,
> o...@redhat.com, s...@mit.edu
> Sent: Friday, June 27, 2014 11:01:27 AM
> Subject: Re: [PATCH RFC tip/core/rcu] Parall
ibm.com,
> t...@linutronix.de, pet...@infradead.org,
> rost...@goodmis.org, dhowe...@redhat.com, eduma...@google.com,
> dvh...@linux.intel.com, fweis...@gmail.com,
> o...@redhat.com, s...@mit.edu
> Sent: Friday, June 27, 2014 10:20:38 AM
> Subject: [PATCH RFC tip/core/rcu] Paralle
An 80-CPU system with a context-switch-heavy workload can require so
many NOCB kthread wakeups that the RCU grace-period kthreads spend several
tens of percent of a CPU just awakening things. This clearly will not
scale well: If you add enough CPUs, the RCU grace-period kthreads would
get behind,
30 matches
Mail list logo