Re: Setting the priority of an IRQ thread

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 17 Jun 2009, GeunSik Lim wrote:
> On Wed, Jun 17, 2009 at 8:21 PM, Remy Bohmer<linux@bohmer.net> wrote:
> > Hello Thomas,
> > Or some kernel developer change the name of the interrupt handler? All
> > different implementations in userspace has to follow as well... And
> > why is 50 the right default to use, and not 30 or 60?
> > For a realtime embedded device this could all be the case, and it is
> > not that strange.

> Um..., I also don't know exact reason that seted irq priority with 50.
> I think that  the value is irq priotiry  is promise in Realtime system.

No, it depends on the system. If your super important device irq needs
to run above all others then you configure it, but it's not a kernel
problem. We have run unimportant irq threads on prio 1 to keep them
out of the way.

> In my case, When I have to change( or set) RT priority about RT
> Kernel thread or Userspace RT applications in a realtime embedded
> device, I change( or set ) priority of RT Process(or thread) after
> consider that irq priority is 50.
 
Again, 50 is a default value. There is no law which prohibits that the
irq priorities can be adjusted to the needs of the system.

The kernel treats by default all irq threads in the same way as it
resembles the mainline behaviour closely. But in contrary to the
mainline hardirq handlers you have now the possibility to change
that. If you are happy with the default then of course you can leave
it as is.

Also a vanilla non-rt kernel comes up with defaults and gives you
enough freedom to customize it to your needs. preempt-rt gives you
some more knobs to tweak and of course an easier way to shoot yourself
into the foot.

Thanks,

	tglx