Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 25 Mar 2005, Ingo Molnar wrote:
> * Esben Nielsen <simlo@phys.au.dk> wrote:
>
> > I like the idea of having the scheduler take care of it - it is a very
> > optimal coded queue-system after all. That will work on UP but not on
> > SMP. Having the unlock operation to set the mutex in a "partially
> > owned" state will work better. The only problem I see, relative to
> > Ingo's implementation, is that then the awoken task have to go in and
> > change the state of the mutex, i.e. it has to lock the wait_lock
> > again. Will the extra schedulings being the problem happen offen
> > enough in practise to have the extra overhead?
>
> i think this should be covered by the 'unschedule/unwakeup' feature,
> mentioned in the latest mails.
>

The first implementation would probably just be the setting of a "pending
owner" bit. But the better one may be to unschedule. But, what would the
overhead be for unscheduling. Since you need to grab the run queue locks
for that. This might make for an interesting case study. The waking up of
a process who had the lock stolen may not happen that much.  The lock
stealing, would (as I see in my runs) happen quite a bit though. But on
UP, the waking of the robbed owner, would never happen, unless it also
owned a lock that a higher priority process wanted.

-- Steve