On Wed, 17 Jun 2009, GeunSik Lim wrote: > On Wed, Jun 17, 2009 at 8:21 PM, Remy Bohmer<linux@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
