On Wed, 2015-02-04 at 13:06 +0100, Peter Zijlstra wrote:
> On Tue, Feb 03, 2015 at 11:43:36AM -0800, Tim Chen wrote:
> > That's true. We cannot have the lock grabbed by a new write
> > contender as any new writer contender of the lock will be
> > queued by the OSQ logic. Only the
> > thread doin
On Tue, Feb 03, 2015 at 11:43:36AM -0800, Tim Chen wrote:
> That's true. We cannot have the lock grabbed by a new write
> contender as any new writer contender of the lock will be
> queued by the OSQ logic. Only the
> thread doing the optimistic spin is attempting write lock.
> In other word,
On Tue, 2015-02-03 at 13:04 -0800, Jason Low wrote:
> On Tue, 2015-02-03 at 11:43 -0800, Tim Chen wrote:
> > On Tue, 2015-02-03 at 09:54 -0800, Jason Low wrote:
> > > On Tue, 2015-02-03 at 09:16 -0800, Tim Chen wrote:
> > > > > > >
> > > > > > > + if (READ_ONCE(sem->owner))
> > > > > > > +
On Tue, 2015-02-03 at 11:43 -0800, Tim Chen wrote:
> On Tue, 2015-02-03 at 09:54 -0800, Jason Low wrote:
> > On Tue, 2015-02-03 at 09:16 -0800, Tim Chen wrote:
> > > > > >
> > > > > > + if (READ_ONCE(sem->owner))
> > > > > > + return true; /* new owner, continue spinning */
> > > > >
On Tue, 2015-02-03 at 09:54 -0800, Jason Low wrote:
> On Tue, 2015-02-03 at 09:16 -0800, Tim Chen wrote:
> > > > >
> > > > > + if (READ_ONCE(sem->owner))
> > > > > + return true; /* new owner, continue spinning */
> > > > > +
> > > >
> > > > Do you have some comparison data of wh
On Tue, 2015-02-03 at 09:16 -0800, Tim Chen wrote:
> > > >
> > > > + if (READ_ONCE(sem->owner))
> > > > + return true; /* new owner, continue spinning */
> > > > +
> > >
> > > Do you have some comparison data of whether it is more advantageous
> > > to continue spinning when
> > >
> > > + if (READ_ONCE(sem->owner))
> > > + return true; /* new owner, continue spinning */
> > > +
> >
> > Do you have some comparison data of whether it is more advantageous
> > to continue spinning when owner changes? After the above change,
> > rwsem will behave more like a s
On Sat, 2015-01-31 at 13:14 -0800, Davidlohr Bueso wrote:
> - owner changes from nil: implies that a writer now holds the mutex. Why
Err... that should say rwsem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Sat, 2015-01-31 at 10:29 +0100, Peter Zijlstra wrote:
> On Fri, Jan 30, 2015 at 01:14:26AM -0800, Davidlohr Bueso wrote:
> > +++ b/kernel/locking/rwsem-xadd.c
> > @@ -337,21 +337,30 @@ static inline bool owner_running(struct rw_semaphore
> > *sem,
> > static noinline
> > bool rwsem_spin_on_ow
On Fri, Jan 30, 2015 at 01:14:26AM -0800, Davidlohr Bueso wrote:
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -337,21 +337,30 @@ static inline bool owner_running(struct rw_semaphore
> *sem,
> static noinline
> bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner)
> {
> +
On Fri, 2015-01-30 at 17:51 -0800, Tim Chen wrote:
> On Fri, 2015-01-30 at 01:14 -0800, Davidlohr Bueso wrote:
> > When readers hold the semaphore, the ->owner is nil. As such,
> > and unlike mutexes, '!owner' does not necessarily imply that
> > the lock is free. This will cause writers to potentia
On Fri, 2015-01-30 at 01:14 -0800, Davidlohr Bueso wrote:
> When readers hold the semaphore, the ->owner is nil. As such,
> and unlike mutexes, '!owner' does not necessarily imply that
> the lock is free. This will cause writers to potentially spin
> excessively as they've been mislead to thinking
12 matches
Mail list logo
