On 07/16/2014 09:14 AM, Paul E. McKenney wrote:
> On Mon, Jul 14, 2014 at 09:27:00AM -0400, Pranith Kumar wrote:
>> On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote:
>>>
>>> They ensure that any RCU read-side critical sections that took place before
>>> the current (or previous)
On Mon, Jul 14, 2014 at 09:27:00AM -0400, Pranith Kumar wrote:
> On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote:
> >
> > They ensure that any RCU read-side critical sections that took place before
> > the current (or previous) idle/userspace period on the remote CPU in
> > question are
On Mon, Jul 14, 2014 at 09:27:00AM -0400, Pranith Kumar wrote:
On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote:
They ensure that any RCU read-side critical sections that took place before
the current (or previous) idle/userspace period on the remote CPU in
question are seen as
On 07/16/2014 09:14 AM, Paul E. McKenney wrote:
On Mon, Jul 14, 2014 at 09:27:00AM -0400, Pranith Kumar wrote:
On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote:
They ensure that any RCU read-side critical sections that took place before
the current (or previous) idle/userspace period
On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote:
>
> They ensure that any RCU read-side critical sections that took place before
> the current (or previous) idle/userspace period on the remote CPU in
> question are seen as having completed before the completion of the current
> grace
On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote:
They ensure that any RCU read-side critical sections that took place before
the current (or previous) idle/userspace period on the remote CPU in
question are seen as having completed before the completion of the current
grace period.
On Fri, Jul 11, 2014 at 06:32:17PM -0400, Pranith Kumar wrote:
> On Fri, Jul 11, 2014 at 5:43 AM, Paul E. McKenney wrote:
> > On Thu, Jul 10, 2014 at 09:17:33PM -0400, Pranith Kumar wrote:
> >> On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
> >> wrote:
> >>
> >> > OK, so ->dynticks_snap is
On Fri, Jul 11, 2014 at 06:32:17PM -0400, Pranith Kumar wrote:
On Fri, Jul 11, 2014 at 5:43 AM, Paul E. McKenney wrote:
On Thu, Jul 10, 2014 at 09:17:33PM -0400, Pranith Kumar wrote:
On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
snip
OK, so
On Fri, Jul 11, 2014 at 5:43 AM, Paul E. McKenney wrote:
> On Thu, Jul 10, 2014 at 09:17:33PM -0400, Pranith Kumar wrote:
>> On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
>> wrote:
>>
>> > OK, so ->dynticks_snap is accessed by only one task, namely the
>> > corresponding RCU grace-period
On Thu, Jul 10, 2014 at 09:17:33PM -0400, Pranith Kumar wrote:
> On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
> wrote:
>
> > OK, so ->dynticks_snap is accessed by only one task, namely the
> > corresponding RCU grace-period kthread. So it can be accessed without
> > any atomic instructions
On Thu, Jul 10, 2014 at 09:17:33PM -0400, Pranith Kumar wrote:
On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
snip
OK, so -dynticks_snap is accessed by only one task, namely the
corresponding RCU grace-period kthread. So it can be accessed without
any
On Fri, Jul 11, 2014 at 5:43 AM, Paul E. McKenney wrote:
On Thu, Jul 10, 2014 at 09:17:33PM -0400, Pranith Kumar wrote:
On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
snip
OK, so -dynticks_snap is accessed by only one task, namely the
corresponding RCU
On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
wrote:
> OK, so ->dynticks_snap is accessed by only one task, namely the
> corresponding RCU grace-period kthread. So it can be accessed without
> any atomic instructions or memory barriers, since all accesses to it are
> single-threaded. On the
On Wed, Jul 9, 2014 at 3:56 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
snip
OK, so -dynticks_snap is accessed by only one task, namely the
corresponding RCU grace-period kthread. So it can be accessed without
any atomic instructions or memory barriers, since all accesses to it are
On Wed, Jul 09, 2014 at 12:00:10AM -0400, Pranith Kumar wrote:
> On Tue, Jul 8, 2014 at 8:07 PM, Paul E. McKenney
> wrote:
> > On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
> >> atomic_add_return() invalidates the cache line in other processors where-as
> >> atomic_read does not.
On Wed, Jul 09, 2014 at 12:00:10AM -0400, Pranith Kumar wrote:
On Tue, Jul 8, 2014 at 8:07 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
atomic_add_return() invalidates the cache line in other processors where-as
On Tue, Jul 8, 2014 at 8:07 PM, Paul E. McKenney
wrote:
> On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
>> atomic_add_return() invalidates the cache line in other processors where-as
>> atomic_read does not. I don't see why we would need invalidation in this
>> case.
>> If
On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
> atomic_add_return() invalidates the cache line in other processors where-as
> atomic_read does not. I don't see why we would need invalidation in this case.
> If indeed it was need a comment would be helpful for readers. Otherwise
>
atomic_add_return() invalidates the cache line in other processors where-as
atomic_read does not. I don't see why we would need invalidation in this case.
If indeed it was need a comment would be helpful for readers. Otherwise doesn't
using atomic_read() make more sense here? RFC!
replace
atomic_add_return() invalidates the cache line in other processors where-as
atomic_read does not. I don't see why we would need invalidation in this case.
If indeed it was need a comment would be helpful for readers. Otherwise doesn't
using atomic_read() make more sense here? RFC!
replace
On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
atomic_add_return() invalidates the cache line in other processors where-as
atomic_read does not. I don't see why we would need invalidation in this case.
If indeed it was need a comment would be helpful for readers. Otherwise
On Tue, Jul 8, 2014 at 8:07 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
atomic_add_return() invalidates the cache line in other processors where-as
atomic_read does not. I don't see why we would need invalidation in this
22 matches
Mail list logo
