On Tue, Jun 06, 2017 at 08:00:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 10:50:48AM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 06, 2017 at 07:23:42PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > > > diff --git
On Tue, Jun 06, 2017 at 08:00:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 10:50:48AM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 06, 2017 at 07:23:42PM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > > > diff --git
On Tue, Jun 06, 2017 at 10:50:48AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 06, 2017 at 07:23:42PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > > index
On Tue, Jun 06, 2017 at 10:50:48AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 06, 2017 at 07:23:42PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > > index
On Tue, Jun 06, 2017 at 07:23:42PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index 3ae8474557df..157654fa436a 100644
> > --- a/kernel/rcu/srcutree.c
> > +++
On Tue, Jun 06, 2017 at 07:23:42PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index 3ae8474557df..157654fa436a 100644
> > --- a/kernel/rcu/srcutree.c
> > +++
On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 3ae8474557df..157654fa436a 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -357,7 +357,7 @@ EXPORT_SYMBOL_GPL(cleanup_srcu_struct);
>
>
On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 3ae8474557df..157654fa436a 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -357,7 +357,7 @@ EXPORT_SYMBOL_GPL(cleanup_srcu_struct);
>
>
On Tue, Jun 06, 2017 at 06:15:51PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote:
> > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
>
> > > As a side note, I am asking myself, though, why we do need the
> > >
On Tue, Jun 06, 2017 at 06:15:51PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote:
> > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
>
> > > As a side note, I am asking myself, though, why we do need the
> > >
On Tue, Jun 06, 2017 at 06:15:51PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote:
> > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
>
> > > As a side note, I am asking myself, though, why we do need the
> > >
On Tue, Jun 06, 2017 at 06:15:51PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote:
> > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
>
> > > As a side note, I am asking myself, though, why we do need the
> > >
On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote:
> On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> > As a side note, I am asking myself, though, why we do need the
> > preempt_disable/enable for the cases where we use the opcodes
> > like lao (atomic load
On Tue, Jun 06, 2017 at 05:27:06PM +0200, Heiko Carstens wrote:
> On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> > As a side note, I am asking myself, though, why we do need the
> > preempt_disable/enable for the cases where we use the opcodes
> > like lao (atomic load
On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> A the same time, the implicit memory barrier of the atomic_inc should be
> even cheaper. In contrast to x86, a full smp_mb seems to be almost for
> free (looks like <= 1 cycle for a bcr 14,0 and no contention). So I
> _think_
On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> A the same time, the implicit memory barrier of the atomic_inc should be
> even cheaper. In contrast to x86, a full smp_mb seems to be almost for
> free (looks like <= 1 cycle for a bcr 14,0 and no contention). So I
> _think_
On Tue, Jun 06, 2017 at 03:08:50PM +0200, Paolo Bonzini wrote:
>
>
> On 06/06/2017 12:53, Peter Zijlstra wrote:
> > On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> >> There would be a slowdown if 1) fast this_cpu_inc is not available and
> >> cannot be implemented (this
On Tue, Jun 06, 2017 at 03:08:50PM +0200, Paolo Bonzini wrote:
>
>
> On 06/06/2017 12:53, Peter Zijlstra wrote:
> > On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> >> There would be a slowdown if 1) fast this_cpu_inc is not available and
> >> cannot be implemented (this
On Tue, Jun 06, 2017 at 05:54:28PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 05:53:57AM -0700, Paul E. McKenney wrote:
> > So the only part of this patch that is needed is the changes to the
> > comments, right? ;-)
>
> Right, although I would suggest putting that requirement (the
On Tue, Jun 06, 2017 at 05:54:28PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 05:53:57AM -0700, Paul E. McKenney wrote:
> > So the only part of this patch that is needed is the changes to the
> > comments, right? ;-)
>
> Right, although I would suggest putting that requirement (the
On Tue, Jun 06, 2017 at 05:37:05PM +0200, Christian Borntraeger wrote:
> On 06/06/2017 05:27 PM, Heiko Carstens wrote:
> > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> >> Adding s390 folks and list
> Only s390 is TSO, arm64 is very much a weak arch.
> >>>
> >>>
On Tue, Jun 06, 2017 at 05:37:05PM +0200, Christian Borntraeger wrote:
> On 06/06/2017 05:27 PM, Heiko Carstens wrote:
> > On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> >> Adding s390 folks and list
> Only s390 is TSO, arm64 is very much a weak arch.
> >>>
> >>>
On Tue, Jun 06, 2017 at 05:53:57AM -0700, Paul E. McKenney wrote:
> So the only part of this patch that is needed is the changes to the
> comments, right? ;-)
Right, although I would suggest putting that requirement (the balanced
lock vs unlock) somewhere as well.
On Tue, Jun 06, 2017 at 05:53:57AM -0700, Paul E. McKenney wrote:
> So the only part of this patch that is needed is the changes to the
> comments, right? ;-)
Right, although I would suggest putting that requirement (the balanced
lock vs unlock) somewhere as well.
On 06/06/2017 05:27 PM, Heiko Carstens wrote:
> On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
>> Adding s390 folks and list
Only s390 is TSO, arm64 is very much a weak arch.
>>>
>>> Right, and thus arm64 can implement a fast this_cpu_inc using LL/SC.
>>> s390 cannot
On 06/06/2017 05:27 PM, Heiko Carstens wrote:
> On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
>> Adding s390 folks and list
Only s390 is TSO, arm64 is very much a weak arch.
>>>
>>> Right, and thus arm64 can implement a fast this_cpu_inc using LL/SC.
>>> s390 cannot
On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> Adding s390 folks and list
> >> Only s390 is TSO, arm64 is very much a weak arch.
> >
> > Right, and thus arm64 can implement a fast this_cpu_inc using LL/SC.
> > s390 cannot because its atomic_inc has implicit memory
On Tue, Jun 06, 2017 at 04:45:57PM +0200, Christian Borntraeger wrote:
> Adding s390 folks and list
> >> Only s390 is TSO, arm64 is very much a weak arch.
> >
> > Right, and thus arm64 can implement a fast this_cpu_inc using LL/SC.
> > s390 cannot because its atomic_inc has implicit memory
Adding s390 folks and list
On 06/06/2017 03:08 PM, Paolo Bonzini wrote:
>
>
> On 06/06/2017 12:53, Peter Zijlstra wrote:
>> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
>>> There would be a slowdown if 1) fast this_cpu_inc is not available and
>>> cannot be implemented
Adding s390 folks and list
On 06/06/2017 03:08 PM, Paolo Bonzini wrote:
>
>
> On 06/06/2017 12:53, Peter Zijlstra wrote:
>> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
>>> There would be a slowdown if 1) fast this_cpu_inc is not available and
>>> cannot be implemented
On 06/06/2017 12:53, Peter Zijlstra wrote:
> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
>> There would be a slowdown if 1) fast this_cpu_inc is not available and
>> cannot be implemented (this usually means that atomic_inc has implicit
>> memory barriers),
>
> I don't get
On 06/06/2017 12:53, Peter Zijlstra wrote:
> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
>> There would be a slowdown if 1) fast this_cpu_inc is not available and
>> cannot be implemented (this usually means that atomic_inc has implicit
>> memory barriers),
>
> I don't get
On Tue, Jun 06, 2017 at 12:53:43PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > There would be a slowdown if 1) fast this_cpu_inc is not available and
> > cannot be implemented (this usually means that atomic_inc has implicit
> > memory
On Tue, Jun 06, 2017 at 12:53:43PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> > There would be a slowdown if 1) fast this_cpu_inc is not available and
> > cannot be implemented (this usually means that atomic_inc has implicit
> > memory
On Tue, Jun 06, 2017 at 02:01:54PM +0200, Paolo Bonzini wrote:
>
>
> On 06/06/2017 13:09, Peter Zijlstra wrote:
> >> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> >> index 36e1f82faed1..681bf6bc04a5 100644
> >> --- a/kernel/rcu/srcutiny.c
> >> +++ b/kernel/rcu/srcutiny.c
> >> @@
On Tue, Jun 06, 2017 at 02:01:54PM +0200, Paolo Bonzini wrote:
>
>
> On 06/06/2017 13:09, Peter Zijlstra wrote:
> >> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> >> index 36e1f82faed1..681bf6bc04a5 100644
> >> --- a/kernel/rcu/srcutiny.c
> >> +++ b/kernel/rcu/srcutiny.c
> >> @@
On 06/06/2017 13:09, Peter Zijlstra wrote:
>> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
>> index 36e1f82faed1..681bf6bc04a5 100644
>> --- a/kernel/rcu/srcutiny.c
>> +++ b/kernel/rcu/srcutiny.c
>> @@ -35,8 +35,8 @@
>>
>> static int init_srcu_struct_fields(struct srcu_struct
On 06/06/2017 13:09, Peter Zijlstra wrote:
>> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
>> index 36e1f82faed1..681bf6bc04a5 100644
>> --- a/kernel/rcu/srcutiny.c
>> +++ b/kernel/rcu/srcutiny.c
>> @@ -35,8 +35,8 @@
>>
>> static int init_srcu_struct_fields(struct srcu_struct
> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> index 36e1f82faed1..681bf6bc04a5 100644
> --- a/kernel/rcu/srcutiny.c
> +++ b/kernel/rcu/srcutiny.c
> @@ -35,8 +35,8 @@
>
> static int init_srcu_struct_fields(struct srcu_struct *sp)
> {
> - sp->srcu_lock_nesting[0] = 0;
> -
> diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> index 36e1f82faed1..681bf6bc04a5 100644
> --- a/kernel/rcu/srcutiny.c
> +++ b/kernel/rcu/srcutiny.c
> @@ -35,8 +35,8 @@
>
> static int init_srcu_struct_fields(struct srcu_struct *sp)
> {
> - sp->srcu_lock_nesting[0] = 0;
> -
On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> There would be a slowdown if 1) fast this_cpu_inc is not available and
> cannot be implemented (this usually means that atomic_inc has implicit
> memory barriers),
I don't get this.
How is per-cpu crud related to being strongly
On Mon, Jun 05, 2017 at 03:09:50PM -0700, Paul E. McKenney wrote:
> There would be a slowdown if 1) fast this_cpu_inc is not available and
> cannot be implemented (this usually means that atomic_inc has implicit
> memory barriers),
I don't get this.
How is per-cpu crud related to being strongly
From: Paolo Bonzini
Linu Cherian reported a WARN in cleanup_srcu_struct when shutting
down a guest that has iperf running on a VFIO assigned device.
This happens because irqfd_wakeup calls srcu_read_lock(>irq_srcu)
in interrupt context, while a worker thread does the same
From: Paolo Bonzini
Linu Cherian reported a WARN in cleanup_srcu_struct when shutting
down a guest that has iperf running on a VFIO assigned device.
This happens because irqfd_wakeup calls srcu_read_lock(>irq_srcu)
in interrupt context, while a worker thread does the same inside
kvm_set_irq.
44 matches
Mail list logo