Re: [RFC][RT][PATCH 3/4] rtmutex: Revert Optimize rt lock wakeup

From: Peter W. Morreale
Date: Tue Jan 04 2011 - 12:16:00 EST


On Tue, 2011-01-04 at 10:47 -0500, Steven Rostedt wrote:
> 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




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