Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1537114
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order |
| Date | 2016-12-06 18:00 +0100 |
| Message-ID | <sLrfY-4AN-57@gated-at.bofh.it> (permalink) |
| References | <sJAdI-4Rh-7@gated-at.bofh.it> <sJAdI-4Rh-33@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
> @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> * mutex_unlock() handing the lock off to us, do a trylock
> * before testing the error conditions to make sure we pick up
> * the handoff.
> + *
> + * For w/w locks, we always need to do this even if we're not
> + * currently the first waiter, because we may have been the
> + * first waiter during the unlock.
> */
> - if (__mutex_trylock(lock, first))
> + if (__mutex_trylock(lock, use_ww_ctx || first))
> goto acquired;
So I'm somewhat uncomfortable with this. The point is that with the
.handoff logic it is very easy to accidentally allow:
mutex_lock(&a);
mutex_lock(&a);
And I'm not sure this doesn't make that happen for ww_mutexes. We get to
this __mutex_trylock() without first having blocked.
> /*
> @@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> spin_unlock_mutex(&lock->wait_lock, flags);
> schedule_preempt_disabled();
>
> - if (!first && __mutex_waiter_is_first(lock, &waiter)) {
> + if (use_ww_ctx && ww_ctx) {
> + /*
> + * Always re-check whether we're in first position. We
> + * don't want to spin if another task with a lower
> + * stamp has taken our position.
> + *
> + * We also may have to set the handoff flag again, if
> + * our position at the head was temporarily taken away.
> + */
> + first = __mutex_waiter_is_first(lock, &waiter);
> +
> + if (first)
> + __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
> + } else if (!first && __mutex_waiter_is_first(lock, &waiter)) {
> first = true;
> __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
> }
So the point is that !ww_ctx entries are 'skipped' during the insertion
and therefore, if one becomes first, it must stay first?
> @@ -728,7 +800,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
> * or we must see its unlock and acquire.
> */
> if ((first && mutex_optimistic_spin(lock, ww_ctx, use_ww_ctx, true)) ||
> - __mutex_trylock(lock, first))
> + __mutex_trylock(lock, use_ww_ctx || first))
> break;
>
> spin_lock_mutex(&lock->wait_lock, flags);
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order Chris Wilson <chris@chris-wilson.co.uk> - 2016-12-01 17:10 +0100
Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order Peter Zijlstra <peterz@infradead.org> - 2016-12-06 16:40 +0100
Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order Peter Zijlstra <peterz@infradead.org> - 2016-12-06 18:00 +0100
[PATCH v2 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
[PATCH v2 10/11] Documentation/locking/ww_mutex: Update the design document Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
[PATCH v2 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Chris Wilson <chris@chris-wilson.co.uk> - 2016-12-01 15:40 +0100
Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Peter Zijlstra <peterz@infradead.org> - 2016-12-06 16:10 +0100
Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Waiman Long <longman@redhat.com> - 2016-12-06 17:10 +0100
Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Waiman Long <longman@redhat.com> - 2016-12-06 19:50 +0100
Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Peter Zijlstra <peterz@infradead.org> - 2016-12-06 20:10 +0100
[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
Re: [PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context Chris Wilson <chris@chris-wilson.co.uk> - 2016-12-01 15:20 +0100
Re: [PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context Daniel Vetter <daniel@ffwll.ch> - 2016-12-01 16:20 +0100
Re: [PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context Peter Zijlstra <peterz@infradead.org> - 2016-12-01 17:30 +0100
[PATCH v2 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
[PATCH v2 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list Nicolai Hähnle <nhaehnle@gmail.com> - 2016-12-01 15:10 +0100
csiph-web