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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
