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
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
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
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
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 the
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
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 but
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
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
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
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 another LOCK
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 involves doing LOCK
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
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 it be complicated to
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 hopefully be
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, 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 really needs
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
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
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
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
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
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
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 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 started
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 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 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
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.
But
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 common
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
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,
> >
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
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 (but perhaps there
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
is zero,
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,
say, if the
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 should
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
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
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 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 the writer
On 10/16, Linus Torvalds wrote:
On Mon, Oct 15, 2012 at 12:10 PM, Oleg Nesterov o...@redhat.com 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
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 memory barriers
do not
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 o...@redhat.com wrote:
This patch adds the new sleeping lock, brw_mutex. Unlike rw_semaphore
it allows multiple writers too, just read and write
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"
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(>write_ctr))) {
> > +
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 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();
+ if
On Mon, Oct 15, 2012 at 12:10 PM, Oleg Nesterov o...@redhat.com 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
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
>
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
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 it
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
58 matches
Mail list logo
