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

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

On Thu, 22 Jun 2006, Thomas Gleixner wrote:

> On Thu, 2006-06-22 at 19:06 +0100, Esben Nielsen wrote:
>>>
>>> Thats a seperate issue. Though you are right.
>>
>> Why not use my original patch and solve both issues?
>> I have even updated it to avoid the double traversal. It also removes
>> one other traversal which shouldn't be needed. (I have not had time
>> to boot the kernel with it, though, but it does compile...:-)
>

Let me comment on your last sentence first:

> We want an immidate propagation.
There is no such thing as "immidiate". The most you can say is that when 
you  return from setscheduler() everything is taken care off. I agree - it 
has to be like that. But I just want to add _effectively_ taken care off. I.e. 
when the within the time setscheduler() has returned _and_ the the 
relevant priorities have time to run things get fixed. No, the users 
should not have to worry about the priorities hanging around, but the 
system can wait with fixing them it is relavant.

> Simply because it does not solve following scenario:
>
> High prio task is blocked on lock and boosts 3 other tasks. Now the
> higher prrio watchdog detects that the high prio task is stuck and
> lowers the priority. You can wake it up as long as you want, the boosted
> task is still busy looping.

Yes, you are right. I have thought about how to fix it, but it will be 
rather ugly. I'll try to see what I can do though, but I am afraid the 
patch might get too big. :-(

(
The same problem may actually always have been present in another corner 
situation:
    A boosts B whichs is blocked interruptible on a lock a boosts C, which 
again boosts D (etc.). A and B are signalled roughly at the same time. A 
wakes up first a decrease the priority of B but not C, because the B runs 
on another CPU, but with lower priority and fixes C. A then stops because C is
fixed. but D still have the A's priority and preempts B, which should fix 
it, but has it's low priority back.
  This situation is not bad because A has already been in the and 
therefore the designer has to think that C D etc already got it's 
priority. That A is later on interrupted shouldn't matter.
)

May I suggest a compromise:

if (in_interrupt() ||
     ( increasing priority && current->prio < prio ) )
            do it Esben's way;
else
            do it Thomas's way;

Then will have fixed most of the problems. We still have the problem of a 
the high priority watchdog task being unbound in setscheduler(), though. 
And if it is called from interrupt and used to descrease the priority, it 
wont work correctly. But it will work for the use in hrtimers, where the 
priority is increased from interrupt.


> And I do not like the idea of invoking the scheduler to do those
> propagations. setscheduler is a synchronous effect in all other cases.
> So it has to be synchronous in the propagation case too.

See my note above about being "immediate". Syncronous is more precise but 
the same argument holds.

>
> Preempt-RT and the dynamic priority adjustment of high resolution timers
> is a different playground and we have to think about that seperately.

*nod*
I agree, although we deffinitely don't want to have too many #ifdef 
CONFIG_PREEMPT_RT around in the code. That makes it far harder to get into 
the mainline tree.

I was bonked for using the other thread for preempt-realtime stuff, so I 
assume this thread is for preempt-realtime stuff only :-)

>
> 	tglx
>
>