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

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

On Tue, 20 Jun 2006, Steven Rostedt wrote:

>
> On Tue, 20 Jun 2006, Esben Nielsen wrote:
>
>> I am sorry. I should have read some more of the code before asking.
>>
>> The only question I have is why the priority of the callback is set to
>> priority of the task calling hrtimer_start() (current->normal_prio). That
>> seems like an odd binding to me. Shouldn't the finding of the priority be moved over to the
>> posix-timer code, where it is needed, and be given as a parameter to
>> hrtimer_start()?
>> In rtmutex.c, where a hrtimer is used as a timeout on a mutex, wouldn't it
>> make more sense to use current->prio than current->normal_prio if the task
>> is boosted when it starts to wait on a mutex.
>
> That seems reasonable.  It probably is a bug to use normal_prio, since we
> really do care what prio is at that time.
>
>>
>>
>> But I am not sure I like the design at all:
>>
>> Let say you have a bunch of callback running at priority 1 and then the
>> next hrt timer with priority 99 expires. Then the callback which
>> is running will be boosted to priority 99. So the overall latency at
>> priority 99 will at least the latency of the worst hrtimer callback.
>
> You mean for those that expire at the same time?
>

No, when the priority 1 (userspace prio) expires just before the 
priority 99.

> I don't think this is a problem, because the run_hrtimer_hres_queue runs
> the hightest priorty callback first, then it adjusts its prio to the next
> priority callback.  See hrtimer_adjust_softirq_prio.
>
>> And worse: What if the callback running is blocked on a mutex? Will the
>> owner of the mutex be boosted as well? Not according to the code in
>> sched.c. Therefore you get priority inversion to priority 1. That is the
>> worst case hrtimer latency is that of priority 1.
>
> I don't see this.

Look at this situation:
softirq-hrt, running some callback, is priority 1 (US prio as always) 
blocked for a mutex owned by some task, A. This now have priority 1 (in 
the worst case).The HRT interrupt comes and calls setscheduler(... prio 99).
That doesn't change the priority of task A as far as I can see from the code.
So in effect the priority 99 callback will wait for task A which is still
priority 1. That is a priority inversion.

>
>>
>> Therefore, a simpler and more robust design would be to give the thread
>> priority 99 as a default - just as the posix_cpu_timer thread. Then the
>> system designer can move it around with chrt when needed.
>> In fact you can say the current design have both the worst cases of having
>> it running as priority 99 and at priority 1!
>
> I still don't see this happening.

The two worst cases are:
1) The system wide system 99 worst case latency is at least that of the 
longest callback.
2) The worst case latency of softirq-hrt is that of priority 1.

If you could set it by chrt you could at least choose which evil thing you 
want.

>
>>
>> Another complicated design would be to make a task for each priority.
>> Then the interrupt wakes the highest priority one, which handles the first
>> callback and awakes the next one etc.
>
> Don't think that is necessary.

Me neither :-) Running sofhtirq-hrt at priority 99 - or whatever is 
set by chrt - should be sufficient.

>
> -- Steve
>

Esben