On Thu, Oct 18, 2012 at 9:00 AM, Mikulas Patocka wrote:
>
> What is the procedure for making changes that require support of
> architectures? It is trivial to make a patch that moves this into
> arch-specific includes, the problem is that the patch break all the
> architectures - I wrote support f
This patch looks sensible.
I'd apply either this or my previous patch that adds synchronize_rcu() to
percpu_up_write.
This patch avoids the memory barrier on non-x86 cpus in percpu_up_read, so
it is faster than the previous approach.
Mikulas
On Thu, 18 Oct 2012, Lai Jiangshan wrote:
> -
On Tue, 16 Oct 2012, Linus Torvalds wrote:
> [ Architecture people, note the potential new SMP barrier! ]
>
> On Tue, Oct 16, 2012 at 4:30 PM, Mikulas Patocka wrote:
> > + /*
> > +* The lock is considered unlocked when p->locked is set to false.
> > +* Use barrier prevent
On Thu, 18 Oct 2012, Steven Rostedt wrote:
> On Thu, 2012-10-18 at 10:18 +0800, Lai Jiangshan wrote:
> > >
> > > Looking at the patch, you are correct. The read side doesn't need the
> > > memory barrier as the worse thing that will happen is that it sees the
> > > locked = false, and will just
On Wed, 17 Oct 2012, Steven Rostedt wrote:
> On Wed, Oct 17, 2012 at 11:07:21AM -0400, Mikulas Patocka wrote:
> > >
> > > Even the previous patch is applied, percpu_down_read() still
> > > needs mb() to pair with it.
> >
> > percpu_down_read uses rcu_read_lock which should guarantee that memor
On Thu, 18 Oct 2012, Lai Jiangshan wrote:
> On 10/18/2012 04:28 AM, Steven Rostedt wrote:
> > On Wed, Oct 17, 2012 at 11:07:21AM -0400, Mikulas Patocka wrote:
> >>>
> >>> Even the previous patch is applied, percpu_down_read() still
> >>> needs mb() to pair with it.
> >>
> >> percpu_down_read use
On Thu, 2012-10-18 at 10:18 +0800, Lai Jiangshan wrote:
> >
> > Looking at the patch, you are correct. The read side doesn't need the
> > memory barrier as the worse thing that will happen is that it sees the
> > locked = false, and will just grab the mutex unnecessarily.
>
>
On 10/18/2012 04:28 AM, Steven Rostedt wrote:
> On Wed, Oct 17, 2012 at 11:07:21AM -0400, Mikulas Patocka wrote:
>>>
>>> Even the previous patch is applied, percpu_down_read() still
>>> needs mb() to pair with it.
>>
>> percpu_down_read uses rcu_read_lock which should guarantee that memory
>> acce
On Wed, Oct 17, 2012 at 11:07:21AM -0400, Mikulas Patocka wrote:
> >
> > Even the previous patch is applied, percpu_down_read() still
> > needs mb() to pair with it.
>
> percpu_down_read uses rcu_read_lock which should guarantee that memory
> accesses don't escape in front of a rcu-protected sec
Hi
On Wed, 17 Oct 2012, Lai Jiangshan wrote:
> On 10/17/2012 10:23 AM, Linus Torvalds wrote:
> > [ Architecture people, note the potential new SMP barrier! ]
> >
> > On Tue, Oct 16, 2012 at 4:30 PM, Mikulas Patocka
> > wrote:
> >> + /*
> >> +* The lock is considered unlocked whe
> a later stores, and stores are viewed in program order, so all x86
> stores have "release consistency" modulo the theoretical PPro bugs
> (that I don't think we actually ever saw in practice).
We did seem the for real. The PPro is on its way out however so I hardly
thing we care about optimising
On 10/17/2012 10:23 AM, Linus Torvalds wrote:
> [ Architecture people, note the potential new SMP barrier! ]
>
> On Tue, Oct 16, 2012 at 4:30 PM, Mikulas Patocka wrote:
>> + /*
>> +* The lock is considered unlocked when p->locked is set to false.
>> +* Use barrier prevent re
[ Architecture people, note the potential new SMP barrier! ]
On Tue, Oct 16, 2012 at 4:30 PM, Mikulas Patocka wrote:
> + /*
> +* The lock is considered unlocked when p->locked is set to false.
> +* Use barrier prevent reordering of operations around p->locked.
> +*/
Hi
When I read my patch 62ac665ff9fc07497ca524bd20d6a96893d11071 again, it
turns out that it is missing a barrier in percpu_up_write. Please apply
this.
Mikulas
---
percpu-rwsem: use barrier in unlock path
Fix missing barrier in patch 62ac665ff9fc07497ca524bd20d6a96893d11071.
The lock is co
14 matches
Mail list logo
