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. ... here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
