Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1619160 > unrolled thread

Re: [PATCH -v6 10/13] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()

Started byDarren Hart <dvhart@infradead.org>
First post2017-04-08 01:40 +0200
Last post2017-04-08 01:40 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH -v6 10/13] futex,rt_mutex: Restructure  rt_mutex_finish_proxy_lock() Darren Hart <dvhart@infradead.org> - 2017-04-08 01:40 +0200

#1619160 — Re: [PATCH -v6 10/13] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()

FromDarren Hart <dvhart@infradead.org>
Date2017-04-08 01:40 +0200
SubjectRe: [PATCH -v6 10/13] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()
Message-ID<ttLDX-5Wh-3@gated-at.bofh.it>
On Fri, Apr 07, 2017 at 04:30:59PM -0700, Darren Hart wrote:
> On Wed, Mar 22, 2017 at 11:35:57AM +0100, Peter Zijlstra wrote:
> > With the ultimate goal of keeping rt_mutex wait_list and futex_q
> > waiters consistent we want to split 'rt_mutex_futex_lock()' into finer
> 
> I want to be clear that I understand why this patch is needed - as it actually
> moves both the waiter removal and the rt_waiter freeing under the hb lock while
> you've been working to be less dependent on the hb lock.
> 
> Was inconsistency of the rt_mutex wait_list and the futex_q waiters a problem
> before this patch series, or do the previous patches make this one necessary?

Ah, this is a follow-on to the issue described in 7 of 10. Nevermind.

-- 
Darren Hart
VMware Open Source Technology Center

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web