[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RT patch acceptance
Andi Kleen wrote:
> 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.

That is the basic idea but is being applied by default.
There is nothing more happening here than pushing the limits
of the design. Certainly there will be some inefficiencies
introduced in the process where some interrupt payload
would have been more efficiently executed in exception
context. If it makes sense on a system-wide basis to
do so, it can be reverted on a case-by-case basis. This is
after all experimental code.

Yet there are other factors which influence the decision
of a running context for the interrupt payload. Depending
on how other code in the system best synchronizes with the
payload, minimizing interrupt disable time in either
payload code and/or coordinating code, etc..

> Most spinlocks only protect small code parts. Those that protect
> larger codes can probably use optionally some different lock.
> But dont attack it with "one size fits all" locking please.

This another case of a sweeping change to the default
behavior. Again an experiment to push the limits of the
given design. Clearly we aren't buying anything to trade off
a spinlock protecting the update of a single pointer with a
blocking lock and associated context switching. But it does
demonstrate code previously relying on synchronization via
polled lock faired remarkably well with preemptive blocking


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-27 01:49    [W:0.435 / U:8.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site