lkml.org 
[lkml]   [2006]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1)
From
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/

\
 
 \ /
  Last update: 2006-06-22 11:31    [W:0.140 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site