Re: Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1)

[Esben Nielsen <nielsen.esben@googlemail.com>]

On Wed, 21 Jun 2006, Ingo Molnar wrote:

> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > On Wed, 2006-06-21 at 16:43 +0100, Esben Nielsen wrote:
> > > What about the patch below. It compiles and my UP labtop runs fine, but I
> > > haven't otherwise tested it.  My labtop runs RTExec without hichups
> > > until now.
> >
> > NAK, it puts the burden into the lock path and also does a remove /
> > add which results in walking the chain twice.
> >
> > Find an version against the code in -mm below. Not too much tested
> > yet.
>
> i like this one - it does the prio fixup where it should be done.

I disagree. I think the work should be done by the task which is blocked.
I can't see the work belongs to the one calling setschedule() - especially 
if that is in interrupt context.

A good principle in real-time system programming is to push at most work 
as possible to as low a priority as possible while still meeting the required 
deadlines. If you don't, you unneedingly increase the latency associated 
with the higher priority.

Let us say you the increase the priority of a task with setscheduler():
The espected latency can never be better than the one associated with the 
current task, nor can it be better than the target priority. Therefore the 
job of fixing the priorities should be done in the lowest priority of
current's priority and the target priority.

Let us say you the decrease the priority of a task with setscheduler():
You need to boost tasks out of the high priority with the latency 
associated with that priority, but the overall latency can never be 
expected to be higher that the priority of at which setscheduler() is 
running. Therefore the job of fixing the priorities should be donee in the 
lowest priority of the current priority and the previous priority of the 
target task.

Neither of the patches by Thomas and me does it optimal in all cases.

Esben

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