Date: Fri, 15 Dec 2000 21:01:36 +0100 From: Bernd Walter <ticso@cicely5.cicely.de> To: =?iso-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, John Baldwin <jhb@FreeBSD.ORG>, Matthew Jacob <mjacob@feral.com>, alpha@FreeBSD.ORG Subject: Re: mutex/ithread jitters? Message-ID: <20001215210136.C62048@cicely5.cicely.de> In-Reply-To: <Pine.LNX.4.10.10012142207190.1637-100000@linux.local>; from groudier@club-internet.fr on Thu, Dec 14, 2000 at 10:29:38PM %2B0100 References: <14905.6815.2347.450995@grasshopper.cs.duke.edu> <Pine.LNX.4.10.10012142207190.1637-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 14, 2000 at 10:29:38PM +0100, Gérard Roudier wrote: > > > On Thu, 14 Dec 2000, Andrew Gallatin wrote: > > > John Baldwin writes: > > > > > > Sounds like lost interrupts. Possibly the interrupt isn't being enabled > > > properly after the ithread finishes running the handler. > > > > Maybe it is time to accept defeat on squelching interrupts at their source > > and leave the IPL raised until the handler is run? > > I am not an arch. guy and I will be fixed by jhb for sure :). Thanks by > advance Jhon for teaching me. :) > > My understanding is that Alpha is actually IPL based and masking using > actual level will kill most advantages if threading interrupts, at least > for level sensitive. My probably false understanding let me think that > result will be increase of interrupt latency without any gain in anything > by threading interrupt handlers. In my understanding the reason for implementing ithread was not to get a better response time but it is neccessary to make use of mutexes for interupt processing. Maybe it's better schedule an ithread only if we need to block which should be unlikely if designed properly and keep IPL raised if sensefull for the platform. But I'm far away from being capable of implementing this. Anyway - if the 4100 has a similar behavour as the PC164 had I'm more willing to believe that the PC164 is in reality not broken. I fact my PC164 masked ints fine several times until it stoped which sounds similar to what is being said for the 4100. Another point is that there are lots of MBs in tsunami_intr_enable/disable especialy the dups are questionable - what's the reason not trusting a single one? But I can't see where writing to hardware is enshured - are the registers marked non-cacheable - but then why an mb? I asume 4100 is tsunami based as I can't find any reference in alpha/dec_kn300.c for defining of platform.intr_disable/enable. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001215210136.C62048>