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

[Steven Rostedt]

On Tue, 20 Jun 2006, Esben Nielsen wrote:
> >>
> >> 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.

So you are worried about a priority 1 timer running when the 99 priority
timer expires?  In this case we should up the timer softirq to 99 and make
the currently running timer just like a critical section.  So the latency
would be just the time of the longest running timer callback.

>
> > 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.

OK, that sounds like a bug.

>
> >
> >>
> >> 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.

If the above bug is fixed, that should read "at most" that of the longest
callback.

> 2) The worst case latency of softirq-hrt is that of priority 1.

We really do need the softirq-hrt dynamic. For what I deal with it helps a
lot.  I want the sleeping high priority task wake up when its timer goes
off, and I don't want it preempted when it's not sleeping by timers of
lower priority tasks.

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

Doesn't work for my situation. Unless I tell the application programers to
up the timer softirq-hrt just before the highest prio thread goes to
sleep. But they are Java programmers and I don't expect them to do this ;)

>
> >
> >>
> >> 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.

No, I think fixing the bug you found is better :)

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