Date: Fri, 15 Dec 2000 13:19:24 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bernd Walter <ticso@cicely5.cicely.de> Cc: alpha@FreeBSD.org, Matthew Jacob <mjacob@feral.com>, Andrew Gallatin <gallatin@cs.duke.edu>, =?iso-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Subject: Re: mutex/ithread jitters? Message-ID: <XFMail.001215131924.jhb@FreeBSD.org> In-Reply-To: <20001215210136.C62048@cicely5.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-Dec-00 Bernd Walter wrote: > 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. This is sort of what light weight context switches for ithreads will do. > 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. Good question. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.001215131924.jhb>