On Fri, 26 Oct 2012, Oleg Nesterov wrote:
> > The code is different, but it can be changed to use percpu rw semaphores
> > (if we add percpu_down_write_trylock).
>
> I don't really understand how you can make percpu_down_write_trylock()
> atomic so that it can be called under br_write_lock(vfsm
On 10/26, Mikulas Patocka wrote:
>
> On Fri, 26 Oct 2012, Oleg Nesterov wrote:
>
> I didn't know about. The code is not reusable, and it doesn't really do
> locking.
That was my main point.
As for the changing fs/namespace.c to use percpu_rwsem, I am not sure
it is that simple and even worthwhile
On Fri, 26 Oct 2012, Oleg Nesterov wrote:
> On 10/26, Dave Chinner wrote:
> >
> > On Thu, Oct 25, 2012 at 10:09:31AM -0400, Mikulas Patocka wrote:
> > >
> > > Yes, mnt_want_write()/mnt_make_readonly() do the same thing as percpu rw
> > > semaphores. I think you can convert mnt_want_write()/mnt_m
On 10/26, Dave Chinner wrote:
>
> On Thu, Oct 25, 2012 at 10:09:31AM -0400, Mikulas Patocka wrote:
> >
> > Yes, mnt_want_write()/mnt_make_readonly() do the same thing as percpu rw
> > semaphores. I think you can convert mnt_want_write()/mnt_make_readonly()
> > to use percpu rw semaphores and remove
On Thu, Oct 25, 2012 at 10:09:31AM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 24 Oct 2012, Dave Chinner wrote:
>
> > On Fri, Oct 19, 2012 at 06:54:41PM -0400, Mikulas Patocka wrote:
> > >
> > >
> > > On Fri, 19 Oct 2012, Peter Zijlstra wrote:
> > >
> > > > > Yes, I tried this approach - it i
On Wed, 24 Oct 2012, Dave Chinner wrote:
> On Fri, Oct 19, 2012 at 06:54:41PM -0400, Mikulas Patocka wrote:
> >
> >
> > On Fri, 19 Oct 2012, Peter Zijlstra wrote:
> >
> > > > Yes, I tried this approach - it involves doing LOCK instruction on read
> > > > lock, remembering the cpu and doing a
On Fri, Oct 19, 2012 at 06:54:41PM -0400, Mikulas Patocka wrote:
>
>
> On Fri, 19 Oct 2012, Peter Zijlstra wrote:
>
> > > Yes, I tried this approach - it involves doing LOCK instruction on read
> > > lock, remembering the cpu and doing another LOCK instruction on read
> > > unlock (which will
Hi Mikulas,
On 10/22, Mikulas Patocka wrote:
>
> On Fri, 19 Oct 2012, Oleg Nesterov wrote:
>
> > On 10/19, Mikulas Patocka wrote:
> > >
> > > synchronize_rcu() is way slower than msleep(1) -
> >
> > This depends, I guess. but this doesn't mmatter,
> >
> > > so I don't see a reason
> > > why should
On Fri, 19 Oct 2012, Oleg Nesterov wrote:
> On 10/19, Mikulas Patocka wrote:
> >
> > synchronize_rcu() is way slower than msleep(1) -
>
> This depends, I guess. but this doesn't mmatter,
>
> > so I don't see a reason
> > why should it be complicated to avoid msleep(1).
>
> I don't think this
On Fri, 19 Oct 2012, Peter Zijlstra wrote:
> > Yes, I tried this approach - it involves doing LOCK instruction on read
> > lock, remembering the cpu and doing another LOCK instruction on read
> > unlock (which will hopefully be on the same CPU, so no cacheline bouncing
> > happens in the comm
On Thu, Oct 18, 2012 at 07:57:47PM +0200, Oleg Nesterov wrote:
> On 10/18, Paul E. McKenney wrote:
> >
> > On Thu, Oct 18, 2012 at 06:24:09PM +0200, Oleg Nesterov wrote:
> > >
> > > I thought that you meant that without mb() brw_start_write() can
> > > race with brw_end_read() and hang forever.
> >
On 10/19, Peter Zijlstra wrote:
>
> But using preempt_{disable,enable} and using synchronize_sched() would
> be better (for PREEMPT_RCU) although it wouldn't fix anything
> fundamental.
BTW, I agree. I didn't even notice percpu-rwsem.h uses _rcu, not _sched.
> Fine goal, although somewhat arch sp
On 10/19, Mikulas Patocka wrote:
>
> synchronize_rcu() is way slower than msleep(1) -
This depends, I guess. but this doesn't mmatter,
> so I don't see a reason
> why should it be complicated to avoid msleep(1).
I don't think this really needs complications. Please look at this
patch for example
On Fri, 2012-10-19 at 11:32 -0400, Mikulas Patocka wrote:
> So if you can do an alternative implementation without RCU, show it.
Uhm,,. no that's not how it works. You just don't push through crap like
this and then demand someone else does it better.
But using preempt_{disable,enable} and using
On Fri, 19 Oct 2012, Peter Zijlstra wrote:
> On Thu, 2012-10-18 at 15:28 -0400, Mikulas Patocka wrote:
> >
> > On Thu, 18 Oct 2012, Oleg Nesterov wrote:
> >
> > > Ooooh. And I just noticed include/linux/percpu-rwsem.h which does
> > > something similar. Certainly it was not in my tree when I s
On Thu, 2012-10-18 at 15:28 -0400, Mikulas Patocka wrote:
>
> On Thu, 18 Oct 2012, Oleg Nesterov wrote:
>
> > Ooooh. And I just noticed include/linux/percpu-rwsem.h which does
> > something similar. Certainly it was not in my tree when I started
> > this patch... percpu_down_write() doesn't allow
On Thu, 18 Oct 2012, Oleg Nesterov wrote:
> Ooooh. And I just noticed include/linux/percpu-rwsem.h which does
> something similar. Certainly it was not in my tree when I started
> this patch... percpu_down_write() doesn't allow multiple writers,
> but the main problem it uses msleep(1). It shoul
On 10/18, Paul E. McKenney wrote:
>
> On Thu, Oct 18, 2012 at 06:24:09PM +0200, Oleg Nesterov wrote:
> >
> > I thought that you meant that without mb() brw_start_write() can
> > race with brw_end_read() and hang forever.
> >
> > But probably you meant that we need the barriers to ensure that,
> > s
On Thu, Oct 18, 2012 at 06:24:09PM +0200, Oleg Nesterov wrote:
> On 10/17, Paul E. McKenney wrote:
> >
> > On Wed, Oct 17, 2012 at 06:37:02PM +0200, Oleg Nesterov wrote:
> > > On 10/16, Paul E. McKenney wrote:
> > > >
> > > > Suppose that the writer arrives and sees that the value of the counter
>
On 10/17, Paul E. McKenney wrote:
>
> On Wed, Oct 17, 2012 at 06:37:02PM +0200, Oleg Nesterov wrote:
> > On 10/16, Paul E. McKenney wrote:
> > >
> > > Suppose that the writer arrives and sees that the value of the counter
> > > is zero,
> >
> > after synchronize_sched(). So there are no readers (bu
On Wed, Oct 17, 2012 at 06:59:02PM +0200, Oleg Nesterov wrote:
> On 10/16, Linus Torvalds wrote:
> >
> > On Mon, Oct 15, 2012 at 12:10 PM, Oleg Nesterov wrote:
> > > This patch adds the new sleeping lock, brw_mutex. Unlike rw_semaphore
> > > it allows multiple writers too, just "read" and "write"
On Wed, Oct 17, 2012 at 06:37:02PM +0200, Oleg Nesterov wrote:
> On 10/16, Paul E. McKenney wrote:
> >
> > On Tue, Oct 16, 2012 at 05:56:23PM +0200, Oleg Nesterov wrote:
> > > >
> > > > I believe that you need smp_mb() here.
> > >
> > > I don't understand why...
> > >
> > > > The wake_up_all()'s me
On 10/16, Linus Torvalds wrote:
>
> On Mon, Oct 15, 2012 at 12:10 PM, Oleg Nesterov wrote:
> > This patch adds the new sleeping lock, brw_mutex. Unlike rw_semaphore
> > it allows multiple writers too, just "read" and "write" are mutually
> > exclusive.
>
> So those semantics just don't sound sane.
On 10/16, Paul E. McKenney wrote:
>
> On Tue, Oct 16, 2012 at 05:56:23PM +0200, Oleg Nesterov wrote:
> > >
> > > I believe that you need smp_mb() here.
> >
> > I don't understand why...
> >
> > > The wake_up_all()'s memory barriers
> > > do not suffice because some other reader might have awakened
On Mon, Oct 15, 2012 at 12:10 PM, Oleg Nesterov wrote:
> This patch adds the new sleeping lock, brw_mutex. Unlike rw_semaphore
> it allows multiple writers too, just "read" and "write" are mutually
> exclusive.
So those semantics just don't sound sane. It's also not what any kind
of normal "rw" l
On Tue, Oct 16, 2012 at 05:56:23PM +0200, Oleg Nesterov wrote:
> Paul, thanks for looking!
>
> On 10/15, Paul E. McKenney wrote:
> >
> > > +void brw_start_read(struct brw_mutex *brw)
> > > +{
> > > + for (;;) {
> > > + bool done = false;
> > > +
> > > + preempt_disable();
> > > +
Paul, thanks for looking!
On 10/15, Paul E. McKenney wrote:
>
> > +void brw_start_read(struct brw_mutex *brw)
> > +{
> > + for (;;) {
> > + bool done = false;
> > +
> > + preempt_disable();
> > + if (likely(!atomic_read(&brw->write_ctr))) {
> > + _
On Mon, Oct 15, 2012 at 09:10:18PM +0200, Oleg Nesterov wrote:
> This patch adds the new sleeping lock, brw_mutex. Unlike rw_semaphore
> it allows multiple writers too, just "read" and "write" are mutually
> exclusive.
>
> brw_start_read() and brw_end_read() are extremely cheap, they only do
> thi
This patch adds the new sleeping lock, brw_mutex. Unlike rw_semaphore
it allows multiple writers too, just "read" and "write" are mutually
exclusive.
brw_start_read() and brw_end_read() are extremely cheap, they only do
this_cpu_inc(read_ctr) + atomic_read() if there are no waiting writers.
OTOH
29 matches
Mail list logo
