Re: RT question : softirq and minimal user RT priority

[Steven Rostedt]

On Tue, 2006-04-18 at 04:10 -0400, Mark Hounschell wrote:
> Lee Revell wrote:
> > Please don't trim CC lists
> > 
> 
> Sorry.

No prob ;)

> 
> > On Mon, 2006-04-17 at 09:21 -0400, Mark Hounschell wrote:
> >> Steven Rostedt wrote:
> >>>> Is the smallest usable real-time priority greater than the highest real-time softirq ?
> >>> Nope, you can use any rt priority you want.  It's up to you whether you
> >>> want to preempt the softirqs or not. Be careful, timers may be preempted
> >>> from delivering signals to high priority processes.  I have a patch to
> >>> fix this, but I'm waiting on input from either Thomas Gleixner or Ingo.
> >>>
> >>> -- Steve
> >> I know this is an old thread but I seem to be having a problem similar
> >> to this and I didn't find any real resolution in the archives.
> >>
> >> I'm using the rt16 patch on 2.6.16.5 with complete preemption. I have a
> >> high priority rt compute bound task that isn't getting signals from a
> >> pci cards interrupt handler. Only when I insure the rt priority of the
> >> task is lower than the rt priority of the irq thread ([IRQ 193]) will my
> >> task receive signals.
> >>
> >> Is this a bug? Is the bug in my interrupt handler? Or is this expected
> >> and acceptable?
> > 
> > It's expected if your high priority RT task never gives up the CPU - if
> > this is the case the IRQ thread should have higher priority.
> > 
> > Lee
> 
> The default IRQ threads seem to be at RT priorities 25-49. So a user
> should never have a RT compute bound task at a RT priority higher than
> 25? Doesn't seem quite right. In any case, I have other less compute
> bound lower priority RT tasks also running on the same CPU so my high
> priority RT task must be giving up the CPU somewhere along the line. Why
> is it not able to receive signals? Something is not quite right here.

Those are just defaults, If a user is going to run a higher priority
task and needs the use to those IRQS then they need to adjust the
priorities of the interrupts themselves.

But remember that the softirqs which handle the bottom halve of
interrupts are also threads, and they run at even a lower priority.  So
if the interrupt uses its bottom half to send a signal to the process,
then if you have a RT task lower in priority than the IRQ but higher
than the softirq, it can still prevent the signal being sent.

Could you send a sample program that shows us the problem?  This would
help us out in figuring out what is wrong.  I still suspect that it's a
configuration problem, but who knows, maybe you found an indiscernible
bug.

Also, I've been ask to write a section in an O'Reilly book about how to
use the -rt patch.  Knowing problems that users may have (such as the
one you are experiencing) would help greatly in explaining to others the
proper way to configure their setup.

Thanks,

-- Steve


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