Re: [PATCH -tip/master 2/7] locking/mutex: Document quick lock release when unlocking
From: Davidlohr Bueso
Date: Wed Jul 30 2014 - 14:21:02 EST
On Wed, 2014-07-30 at 08:10 -0700, Jason Low wrote:
> On Sun, 2014-07-27 at 22:18 -0700, Davidlohr Bueso wrote:
> > - * Release the lock, slowpath:
> > + * Release the lock, slowpath.
> > + * At this point, the lock counter is 0 or negative.
> Hmm, so in the !__mutex_slowpath_needs_to_unlock() case, we could enter
> this function with the lock count == 1 right?
Yes, it is possible. So that comment should actually be moved down to:
> > */
> > static inline void
> > __mutex_unlock_common_slowpath(struct mutex *lock, int nested)
> > @@ -684,9 +685,16 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int nested)
> > unsigned long flags;
> > /*
> > - * some architectures leave the lock unlocked in the fastpath failure
> > + * As a performance measurement, release the lock before doing other
> > + * wakeup related duties to follow. This allows other tasks to acquire
> > + * the lock sooner, while still handling cleanups in past unlock calls.
> > + * This can be done as we do not enforce strict equivalence between the
> > + * mutex counter and wait_list.
> > + *
> > + *
> > + * Some architectures leave the lock unlocked in the fastpath failure
> > * case, others need to leave it locked. In the later case we have to
> > - * unlock it here
> > + * unlock it here.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/