Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 18 Apr 2006 12:47:36 -0400 | From | Mark Hounschell <> | Subject | Re: RT question : softirq and minimal user RT priority |
| |
Steven Rostedt wrote: > 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. >
You probably sent this before seeing my next post. The other RT threads are running on a different processor. The task in question is for sure hogging it's CPU. It and the IRQ thread are the only tasks executing on that CPU and the IRQ is a lower RT prio.
> 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. >
I'd be happy to send you sample code if you still think it might help in some way. Let me know. In short the interrupt handler is just using "send_sig" to signal the task. The RT task obviously has a signal handler setup, but is not giving up any cpu time voluntarily. So I guess it is a 'configuration' issue on this end.
I'd certainly be interested in that article BTW.
Mark
- 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/
| ![\](/images/icornerr.gif) |