Messages in this thread | | | Subject | Re: [RFC][RT][PATCH 3/4] rtmutex: Revert Optimize rt lock wakeup | From | "Peter W. Morreale" <> | Date | Tue, 04 Jan 2011 08:19:09 -0700 |
| |
On Mon, 2011-01-03 at 15:22 -0500, Steven Rostedt wrote: > On Mon, 2011-01-03 at 14:06 -0500, Steven Rostedt wrote: > > > > > if (adaptive_wait(&waiter, orig_owner)) > > sleep = 1; > > else > > sleep = 0; > > > > if (sleep) > > > > raw_spin_lock(&lock->wait_lock); > > saved_state = rt_set_current_block_state(saved_state); > > if (!lock->owner && &waiter == rt_mutex_top_waiter(lock)) > > sleep = 0; > > raw_spin_unlock(&lock->wait_lock); > > I may be able to remove the above locks and replace it with: > > saved_state = rt_set_current_blocked_state(saved_state); > if (orig_owner == rt_mutex_owner(lock)) > schedule_rt_mutex(lock); > > -- Steve
Isn't it possible to miss a wakeup here if the waiter becomes preempted?
Recall that adaptive wait is a preemptive wait. Hence the (I believe) original reason we did the adaptive spin in a (transitioning) sleep state.
-PWM
> > > > if (sleep) > > schedule_rt_mutex(lock); > > saved_state = rt_restore_current_blocked_state(saved_state); > > } > > > > Otherwise we can risk the wakeup_next_waiter() missing the wakeup. > > > > To clarify, we want the adaptive_wait() to run as TASK_RUNNING. Then if > > we must sleep, then we must set the state to TASK_UNINTERRUPTIBLE, test > > again if we can still the lock, and if not then sleep. Otherwise, if a > > wakeup happens just before we set the state to TASK_UNINTERRUPTIBLE, > > then we miss the wake up all together. > > > > I can do this change, and see what impact it makes. > > > > I'm also curious if this ever worked? If it did not, then are you sure > > your tests that show the benefit of it was true. I don't have a large > > scale box at my disposal ATM, so I can only see what this does on 4way > > machines. > > > > -- Steve > > > >
| |