- On Jul 2, 2015, at 3:23 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Thu, Jul 02, 2015 at 06:47:47PM +, Mathieu Desnoyers wrote:
>> - On Jul 2, 2015, at 2:35 PM, Ingo Molnar mi...@kernel.org wrote:
>>
>> > * Paul E. McKenney wrote:
>> >
>> >> > And it's not like it
On Thu, Jul 02, 2015 at 06:47:47PM +, Mathieu Desnoyers wrote:
> - On Jul 2, 2015, at 2:35 PM, Ingo Molnar mi...@kernel.org wrote:
>
> > * Paul E. McKenney wrote:
> >
> >> > And it's not like it's that hard to stem the flow of algorithmic
> >> > sloppiness at
> >> > the source, right?
>
On Thu, Jul 02, 2015 at 08:35:57PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > > And it's not like it's that hard to stem the flow of algorithmic
> > > sloppiness at
> > > the source, right?
> >
> > OK, first let me make sure that I understand what you are asking for:
> >
>
- On Jul 2, 2015, at 2:35 PM, Ingo Molnar mi...@kernel.org wrote:
> * Paul E. McKenney wrote:
>
>> > And it's not like it's that hard to stem the flow of algorithmic
>> > sloppiness at
>> > the source, right?
>>
>> OK, first let me make sure that I understand what you are asking for:
>>
>
* Paul E. McKenney wrote:
> > And it's not like it's that hard to stem the flow of algorithmic sloppiness
> > at
> > the source, right?
>
> OK, first let me make sure that I understand what you are asking for:
>
> 1.Completely eliminate synchronize_rcu_expedited() and
> synchronize
On Thu, Jul 02, 2015 at 09:47:19AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 01, 2015 at 09:17:05AM -0700, Paul E. McKenney wrote:
> > > > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstr
* Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 01, 2015 at 09:17:05AM -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> >
> > > > 74b51ee152b6 ("ACPI / osl: speedup grace period in
On Thu, Jul 02, 2015 at 04:50:45AM +0200, Mike Galbraith wrote:
> On Wed, 2015-07-01 at 19:18 -0700, Paul E. McKenney wrote:
>
> > Does their normal workload trigger the condition that results in the
> > expedited grace period? If so, do they use NO_HZ_FULL?
>
> They're having no trouble that I'
On Wed, 2015-07-01 at 19:18 -0700, Paul E. McKenney wrote:
> Does their normal workload trigger the condition that results in the
> expedited grace period? If so, do they use NO_HZ_FULL?
They're having no trouble that I'm aware of, and I definitely would be
made aware. They're not currently usi
On Thu, Jul 02, 2015 at 03:59:55AM +0200, Mike Galbraith wrote:
> On Wed, 2015-07-01 at 18:34 -0700, j...@joshtriplett.org wrote:
> > On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> > > On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > > > On Wed, Jul 01, 2015 at 04:1
On Wed, 2015-07-01 at 18:34 -0700, j...@joshtriplett.org wrote:
> On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> > On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Jul 01, 2015 at 07:0
On Thu, Jul 02, 2015 at 03:11:24AM +0200, Mike Galbraith wrote:
> On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> > >
> > > > That is a bit extre
On Wed, 2015-07-01 at 09:17 -0700, Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> >
> > > That is a bit extreme, Peter.
> >
> > Of course; but I'm really not seeing people taking due
On Wed, Jul 01, 2015 at 02:20:01PM -0700, j...@joshtriplett.org wrote:
> On Wed, Jul 01, 2015 at 01:09:36PM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> > > USB sure, but a backing dev is involved in nfs clients, loopback and all
> > > sorts o
On Wed, Jul 01, 2015 at 01:09:36PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> > USB sure, but a backing dev is involved in nfs clients, loopback and all
> > sorts of block/filesystem like setups.
> >
> > unmount an NFS mount and voila expedit
On Wed, Jul 01, 2015 at 07:02:42PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 01, 2015 at 09:17:05AM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
>
> > > 74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")
> >
> > Really??
On Wed, Jul 01, 2015 at 09:17:05AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> > 74b51ee152b6 ("ACPI / osl: speedup grace period in acpi_os_map_cleanup")
>
> Really???
>
> I am not concerned about this one. After all, one of the first thing
On Wed, Jul 01, 2015 at 04:17:10PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
>
> > That is a bit extreme, Peter.
>
> Of course; but I'm really not seeing people taking due care with them
;-)
> > Are a huge pile of them coming in this merge
On Wed, Jul 01, 2015 at 08:43:54AM -0700, Josh Triplett wrote:
> On Tue, Jun 30, 2015 at 08:37:01PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 30, 2015 at 05:42:14PM -0700, Josh Triplett wrote:
> > > On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
> > > > On Tue, Jun 30, 2015
On Wed, Jul 01, 2015 at 04:08:27PM +0200, Eric Dumazet wrote:
> > OK, I'll bite. Exactly what seems especially vile about it?
>
> Presumably we would need to convert everything to async model
> (call_rcu() and friends),
> but that is a long way to go...
>
> For example, synchronize_srcu_expedite
On Tue, Jun 30, 2015 at 08:37:01PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 30, 2015 at 05:42:14PM -0700, Josh Triplett wrote:
> > On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> > > > On Tue, Jun 3
On Wed, Jul 01, 2015 at 07:00:31AM -0700, Paul E. McKenney wrote:
> That is a bit extreme, Peter.
Of course; but I'm really not seeing people taking due care with them
> Are a huge pile of them coming in this merge window or something?
> What raised your concerns on this issue?
This is complete
> OK, I'll bite. Exactly what seems especially vile about it?
Presumably we would need to convert everything to async model
(call_rcu() and friends),
but that is a long way to go...
For example, synchronize_srcu_expedited() in kvm_set_irq_routing()
really looks overkill.
--
To unsubscribe from t
On Wed, Jul 01, 2015 at 12:12:21PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 30, 2015 at 08:37:01PM -0700, Paul E. McKenney wrote:
> > > Wait, what? Why is anything using traditional (non-S) RCU while *any*
> > > lock is held?
> >
> > In their defense, it is a sleeplock that is never taken excep
On Wed, Jul 01, 2015 at 12:55:11PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 01, 2015 at 12:09:39PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> > > Consider it a fairly weak concern against. Increasing performance seems
> > > like a go
On Wed, Jul 01, 2015 at 12:09:39PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> > Consider it a fairly weak concern against. Increasing performance seems
> > like a good thing in general; I just don't relish the future "feels less
> > resp
On Tue, Jun 30, 2015 at 08:37:01PM -0700, Paul E. McKenney wrote:
> > Wait, what? Why is anything using traditional (non-S) RCU while *any*
> > lock is held?
>
> In their defense, it is a sleeplock that is never taken except when
> rearranging networking configuration. Sometimes they need a grac
On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> Consider it a fairly weak concern against. Increasing performance seems
> like a good thing in general; I just don't relish the future "feels less
> responsive" bug reports that take a long time to track down and turn out
> t
On Tue, Jun 30, 2015 at 05:42:14PM -0700, Josh Triplett wrote:
> On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> > > On Tue, Jun 30, 2015 at 03:12:24PM -0700, Paul E. McKenney wrote:
> > > > On Tue, Jun 3
On Tue, Jun 30, 2015 at 05:15:58PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> > On Tue, Jun 30, 2015 at 03:12:24PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 30, 2015 at 03:00:15PM -0700, j...@joshtriplett.org wrote:
> > > > On Tu
On Tue, Jun 30, 2015 at 04:46:33PM -0700, j...@joshtriplett.org wrote:
> On Tue, Jun 30, 2015 at 03:12:24PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 30, 2015 at 03:00:15PM -0700, j...@joshtriplett.org wrote:
> > > On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> > > > Hello
On Tue, Jun 30, 2015 at 03:12:24PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 30, 2015 at 03:00:15PM -0700, j...@joshtriplett.org wrote:
> > On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > This series contains some highly experimental patches that allow
On Tue, Jun 30, 2015 at 03:00:15PM -0700, j...@joshtriplett.org wrote:
> On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > This series contains some highly experimental patches that allow normal
> > grace periods to take advantage of the work done by concurrent e
On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> Hello!
>
> This series contains some highly experimental patches that allow normal
> grace periods to take advantage of the work done by concurrent expedited
> grace periods. This can reduce the overhead incurred by normal grace
Hello!
This series contains some highly experimental patches that allow normal
grace periods to take advantage of the work done by concurrent expedited
grace periods. This can reduce the overhead incurred by normal grace
periods by eliminating the need for force-quiescent-state scans that
would o
35 matches
Mail list logo
