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

[Esben Nielsen]

On Tue, 20 Jun 2006, Thomas Gleixner wrote:

> On Tue, 2006-06-20 at 18:09 +0100, Esben Nielsen wrote:
> > 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()?
>
> Was the simplest way to do.

Yes, when you only use the hrtimers to implement signals. But what if you 
use them for something different?

> > 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.
>
> Not sure about that.
>
> > 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.
> > 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.
> >
> > 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!
>
> We had this before and it is horrible.

"Horrible" in what respect?

> > 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.
>
> Uurgh. Thats not a serious proposal ?

No, not really. And then a little bit in a generalized way:
The kernel could have these threads as general working threads on which 
all kind of callbacks could be executed at their right priority.
But, ofcourse, having 100 tasks sitting around per CPU is huge waste of 
memory. But maybe some kind of pooling could be made?

As I said in a another mail some time back: Having 100 different RT 
priorities doesn't make sense. You can at most need 10 anyway.

> A nice solution would be to enqueue the timer into the task struct of
> the thread which is target of the signal, wake that thread in a special
> state which only runs the callback and then does the signal delivery.

What if the thread is running?

> The scary thing on this is to get the locking straight, but it might
> well worth to try it. That way we would burden the softirq delivery to
> the thread and maybe save a couple of task switches.
>
> 	tglx

Hmm, a practical thing to do would be to make a system where you can post 
jobs in a thread. These jobs can then be done in thread context 
around schedule or just before the task returns to user-space.

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