Re: 2.6.14-rc3-rt2

[david singleton <dsingleton@mvista.com>]

On Oct 5, 2005, at 9:08 AM, Thomas Gleixner wrote:

> On Wed, 2005-10-05 at 08:58 -0700, david singleton wrote:
> > > Yes. Thats happening. I moved the priority of softirq-timer above
> > > hackbench priority and the problem goes away. I look into this 
> > > further.
> >
> > I had to set the threaded softirqs to real time priorities with the hi
> > thread at 24,
> > the timer thread at 23, net_rx at 22, etc.    I wanted their 
> > priorities
> >   just below the IRQ threads.
> >
> >   The problem was the timer thread.  Other real time threads got in 
> > its
> > way and held off timers.
> >
> > And I had to make a note if any higher priority apps depended on 
> > timers
> > that the timer
> > thread had to be boosted in priority to match that real time threads
> > priority.   It's like
> > the softirqd's timer thread needs priority inheritance.
>
> Well, we had implemented this in one of the previous -rt versions for
> the high resolution timers. It was a bit hacky and I did not come 
> around
> to reimplement it on top of ktimers. This is only a problem for itimers
> and posix interval timers at the moment. The nanosleep variants do not
> suffer from this problem as the wakeup happens directly from the hr
> timer interrupt. That way we have only one instead of two task 
> switches.

When I finally got the IRQ threads priorities straight and the softirqd 
priorities
matched to be right underneath the IRQ priorities the system would run
any benchmark I could throw at it with no problems,   modulo the strange
app that wanted to run at priority 99 and depended on itimers or 
sigarlm . . .

For that case I had to match the softirq timer thread to that of the 
app before
it would run with no problems.

David
> tglx

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