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

From: Esben Nielsen
Date: Thu Jun 22 2006 - 05:27:30 EST


On Wed, 21 Jun 2006, Ingo Molnar wrote:


* Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/