[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RT patch acceptance
On Thu, 2005-05-26 at 22:27 +0200, Andi Kleen wrote:
> > Here, I am talking about separating out the patch, and applying it
> > first, not dropping it from the RT implementation.
> I really dislike the idea of interrupt threads. It seems totally
> wrong to me to make such a fundamental operation as an interrupt
> much slower. If really any interrupts take too long they should
> move to workqueues instead and be preempted there. But keep
> the basic fundamental operations fast please (at least that used to be one
> of the Linux mottos that served it very well for many years, although more
> and more people seem to forget it now)

IRQ threads are configurable. If you don't want them, you CAN turn them
off (if you have already turned them on).

You don't HAVE to turn them on.

The IRQ option option adds "responsiveness" to the not forgotten, but
configurable, "progress, throughput, fairness, resource sharing"
principles of Unix found in the Linux kernel.

A lot of the IRQ stuff is already in bottom halves, where it runs in a
thread sometimes. But when it doesn't, its not preemptable, sometimes
for a long time. Add other non-preemptable regions, and you get big

The IRQ thread option runs SoftIRQd in a thread always, if you want to
configure it that way, and eliminates the IRQ latency burstyness.

As far as the hard IRQs, you can leave them off too, and maybe turn on
one for a while, until you forget that you did that.

Then try another.

Your other questions are probably covered by Ingo's current remarks.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-26 22:58    [W:0.529 / U:22.100 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site