| Date | Fri, 24 Mar 2017 17:37:02 -0700 | From | Darren Hart <> | Subject | Re: [PATCH -v6 04/13] futex,rt_mutex: Provide futex specific rt_mutex API |
| |
On Wed, Mar 22, 2017 at 11:35:51AM +0100, Peter Zijlstra wrote: > Part of what makes futex_unlock_pi() intricate is that > rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop > rt_mutex::wait_lock. > > This means we cannot rely on the atomicy of wait_lock, which we would > like to do in order to not rely on hb->lock so much. > > The reason rt_mutex_slowunlock() needs to drop wait_lock is because it > can race with the rt_mutex fastpath, however futexes have their own > fast path. > > Since futexes already have a bunch of separate rt_mutex accessors, > complete that set and implement a rt_mutex variant without fastpath > for them. > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Got to here and tried to get some testing going while I was reviewing... to find that some of the existing pi test suites LTP/realtime, are not building either. Got a fix, got it into CI, some CI issues, but no obvious fallout from this. So, review will continue...
But, Peter are you testing this with anything in particular?
-- Darren Hart VMware Open Source Technology Center
|