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, Thomas Gleixner wrote:

> On Tue, 2006-06-20 at 19:12 +0100, Esben Nielsen wrote:
> > > > 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.
>
> It is not, that was the reason, why we implemted it. You get arbitrary
> latencies caused by timer storms.

What you are saying is that there is a lot of timers timing out at the 
same time. When that happens you will get them all executed at priority 
99 with the simple setup. In the current design you get them executed in 
order of priority and the task lowers it's priority as it goes along.
If you have a long list of low priority callbacks pending to be executed 
the running one will finish at priority 99 and then the high priority one 
will be put in as the list on the list.

Ok, I see your point: Although you can't preempt the individual callbacks 
you can preempt the loop, which helps on latencies as many timers can 
timeout before they are executed.

> I have to check, whether the priority is propagated when the softirq is
> blocked on a lock. If not its a bug and has to be fixed.

I think the simplest solution would be to add

        if (p->blocked_on)
                wake_up_process(p);

in __setscheduler().

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