Re: RT Mutex patch and tester [PREEMPT_RT]

[hui]

On Wed, Jan 11, 2006 at 06:25:36PM +0100, Esben Nielsen wrote:
> I have done 2 things which might be of interrest:
> 
> II) I changed the priority inheritance mechanism in rt.c,
> optaining the following goals:
> 3) Simpler code. rt.c was kind of messy. Maybe it still is....:-)

Awssome. The code was done in what seems like a hurry and mixes up a
bunch of things that should be seperate out into individual sub-sections.

The allocation of the waiter object on the thread's stack should undergo
some consideration of whether this should be move into a more permanent
store. I haven't looked at an implementation of turnstiles recently, but
I suspect that this is what it actually is and it would eliminate the
moving of waiters to the thread that's is actively running with the lock
path terminal mutex. It works, but it's sloppy stuff.

[loop trickery, priority leanding operations handed off to mutex owner]

> What is gained is that the amount of time where irq and preemption is off
> is limited: One task does it's work with preemption disabled, wakes up the
> next and enable preemption and schedules. The amount of time spend with
> preemption disabled is has a clear upper limit, untouched by how
> complicated and deep the lock structure is.

task_blocks_on_lock() is another place that one might consider seperating
out some bundled functionality into different places in the down()
implementation. I'll look at the preemption stuff next.

Just some ideas. Looks like a decent start.

bill

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