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
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 they have a
chance of acquiring the lock, instead of blocking.
Th
13 matches
Mail list logo
