Re: Interrupt Bottom Half Scheduling

[Peter LaDow <petela@gocougs.wsu.edu>]

On Mon, Feb 14, 2011 at 3:30 PM, Frank Rowand <frank.rowand@gmail.com> wrote:
> On Mon, Feb 14, 2011 at 2:31 PM, Peter LaDow <petela@gocougs.wsu.edu> wrote:
>> How is the scheduling of the hrtimers softirq thread handled?
>>
>> When querying the RT priority of the hrtimer softirq, I get a priority
>> of 50.  But when running a priority 99 thread, we still seem to be
>> getting interrupted.  Shouldn't the hrtimer softirq be put off until
>> the CPU is idle or a lower priority task is running?
>
> Is the hrtimer softirq executing when the priority 99 thread is spinning
> in it's for loop?  Your "jitter Due to Large Number of Timers" email
> said that the lower priority tasks don't seem to be interrupting the
> priority 99 thread.

Did I?  Hmm, well I mean the lower priority task with 100 threads.  At
least I think so.  It is hard to tell.

It seems to me that the softirq thread is the source of the problem.
Since the tight loop is getting such a variety of times (400us of
jitter only while the other process is running) that it does seem that
the loop is getting interrupt.

> The hardware timer interupts will interrupt the priority 99 thread.  The
> cost of these interrupts and the resultant calls to try_to_wake_up()
> of the hrtimer softirq might be quite large considering the rate of
> timer expires you mentioned in your first email.

Sure, we expect the timer interrupt to interfere.  But as we
understand it, the softirq is what schedules the task switch.  The top
half only schedules the bottom half.  But since the bottom half is
priority 50, there shouldn't be any interruption of the priority 99
expect to handle the low level IRQ.

> Out of curiosity, is the system UP or SMP?

UP.  Just a single MPC5349.

pete
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html