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

Ingo Molnar
2005-03-24T10:46:09Z

* Steven Rostedt <rostedt@goodmis.org> wrote:

> I also see this with non rt tasks causing a burst of schedules.
>
> 1. Process A runs and grabs lock L. then finishes its time slice.
> 2. Process B runs and tries to grab Lock L.
> 3. Process A runs and releases lock L.
> 4. __up_mutex gives process B lock L.
> 5. Process A tries to grab lock L.
> 6. Process B runs and releases lock L.
> 7. __up_mutex gives lock L to process A.
> 8. Process B tries to grab lock L again.
> 9. Process A runs...
>
> Here we have more unnecessary schedules. So the condition to grab a lock
> should be:
>
> 1. not owned.
> 2. partially owned, and the owner is not RT.
> 3. partially owned but the owner is RT and so is the grabber, and the
> grabber's priority is >= the owner's priority.

yeah, sounds good - but i'd not make any distinction between RT and
non-RT tasks - just make the rule #3 distinction based on ->prio. In
particular on UP a task should only run when its higher prio, so if a
lock is 'partially owned' then the priority rule should always be true.
(On SMP it's a bit more complex, there the priority rule could make a
real difference.)

Ingo