Message-ID: <42965F43.2010904@timesys.com>
Date: Thu, 26 May 2005 19:44:03 -0400
From: john cooper <john.cooper@timesys.com>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
MIME-Version: 1.0
To: Andi Kleen <ak@muc.de>
CC: Sven-Thorsten Dietrich <sdietrich@mvista.com>, Ingo Molnar <mingo@elte.hu>,
       dwalker@mvista.com, bhuey@lnxw.com, nickpiggin@yahoo.com.au,
       hch@infradead.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
       john cooper <john.cooper@timesys.com>
Subject: Re: RT patch acceptance
References: <20050525005942.GA24893@nietzsche.lynx.com> <1116982977.19926.63.camel@dhcp153.mvista.com> <20050524184351.47d1a147.akpm@osdl.org> <4293DCB1.8030904@mvista.com> <20050524192029.2ef75b89.akpm@osdl.org> <20050525063306.GC5164@elte.hu> <m1br6zxm1b.fsf@muc.de> <1117044019.5840.32.camel@sdietrich-xp.vilm.net> <20050526193230.GY86087@muc.de> <1117138270.1583.44.camel@sdietrich-xp.vilm.net> <20050526202747.GB86087@muc.de>
In-Reply-To: <20050526202747.GB86087@muc.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1877
Lines: 44

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
mutexes.

-john

-- 
john.cooper@timesys.com
-
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/