On Tue, 2011-01-04 at 10:47 -0500, Steven Rostedt wrote:
quoted text
> On Tue, 2011-01-04 at 08:19 -0700, Peter W. Morreale wrote:
> > 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?
> 
> Why? Preemption doesn't change the task state.
> > 
> > Recall that adaptive wait is a preemptive wait.  Hence the (I believe)
> > original reason we did the adaptive spin in a (transitioning)  sleep
> > state.
> 
> Yes it is a preemptive wait, I would not have accepted the patches if it
> was anything else. But preemption is not affected by the state of the
> task. A task could be TASK_RUNNING or TASK_INTERRUPTIBLE or
> TASK_UNINTERRUPTIBLE, and that would not affect how it acts when it is
> preempted.
> 
> -- Steve
> 
> 

My bad.  I thought preemption did change task state.

This still requires the owner to run through try_to_wake_up() and all
its associated overhead only to find out that the waiter is running.  

The assumption I made when I suggested the original concept to Greg was
that if the new owner is running, there is *nothing* to do wrt
scheduling.  If that was a wrong assumption, then, yes, drop the patch
and clean things up.  

If that was a good assumption, then we are leaving 'cycles on the table'
as waking up a running process is a non-zero-overhead path and that is a
bad thing considering how many times spin_unlock() is called on an rt
system.

Bear in mind that this savings scales directly as the number of CPUs
(assuming all are vectored on the lock).  We can only have nr_cpus-1
spinning waiters at any given time, regardless of the number of tasks in
contention.  Perhaps this is too little to worry about on a 4way system,
but I suspect that it could be substantial on larger systems.  

I'll be quiet now as I know little about the intricacies of
preemption/scheduling (obviously) and like Greg, have been removed from
RT kernel work for several years. <sigh>

-PWM




--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/