From: Mark Hounschell <dmarkh@cfl.rr.com>
To: linux-kernel@vger.kernel.org
Cc: Lee Revell <rlrevell@joe-job.com>,
markh@compro.net, Ingo Molnar <mingo@elte.hu>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: RT question : softirq and minimal user RT priority
Date: Tue, 18 Apr 2006 04:10:10 -0400 [thread overview]
Message-ID: <44449EE2.8070907@cfl.rr.com> (raw)
In-Reply-To: <1145286325.16138.26.camel@mindpipe>
Lee Revell wrote:
> Please don't trim CC lists
>
Sorry.
> 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.
Regards
Mark
next prev parent reply other threads:[~2006-04-18 8:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-13 14:27 RT question : softirq and minimal user RT priority Serge Noiraud
2006-01-13 15:53 ` Steven Rostedt
2006-01-17 7:58 ` Serge Noiraud
2006-01-20 8:24 ` Serge Noiraud
2006-04-17 13:21 ` Mark Hounschell
2006-04-17 15:05 ` Lee Revell
2006-04-18 8:10 ` Mark Hounschell [this message]
2006-04-18 10:03 ` Mark Hounschell
2006-04-18 13:31 ` Steven Rostedt
2006-04-18 16:47 ` Mark Hounschell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44449EE2.8070907@cfl.rr.com \
--to=dmarkh@cfl.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markh@compro.net \
--cc=mingo@elte.hu \
--cc=rlrevell@joe-job.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox