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

From: Esben Nielsen
Date: Tue Jun 20 2006 - 16:25:51 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/