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

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2005-03-30 at 20:44 +0100, Esben Nielsen wrote:
> On Wed, 30 Mar 2005, Steven Rostedt wrote:
> 
> > [...] 
> > 
> > Heck, I'll make it bloat city till I get it working, and then tone it
> > down a little :-)  And maybe later we can have a better solution for the
> > BKL.
> > 
> What about removing it alltogether?
> Seriously, how much work would it be to simply remove it and go in and
> make specific locks in all those places the code can't compile?

I would really love to do that!  But I don't have the time or the
knowledge on the effects that would have.

Because of the stupid BKL, I'm going with a combination of your idea and
my idea for the solution of pending owners.  I originally wanted the
stealer of the lock to put the task that was robbed back on the list.
But because of the BKL, you end up with a state that a task can be
blocked by two locks at the same time. This causes hell with priority
inheritance.

So finally, what I'm doing now is to have the lock still pick the
pending owner, and that owner is not blocked on the lock. If another
process comes along and steals the lock, the robbed task goes to a state
as if it was just before calling __down*. So when it wakes up, it checks
to see if it is the pending owner, and if not, then it tries to grab the
lock again, if it doesn't get it, it just calls task_blocks_on_lock
again.

This is the easiest solution so far, but I still like the stealer to put
it back on the list.  But until we get rid of the BKL that wont happen.

-- Steve


-
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/