Date: Fri, 15 Dec 2000 21:10:39 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Bernd Walter <ticso@cicely5.cicely.de> 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: <Pine.LNX.4.10.10012152037330.1578-100000@linux.local> In-Reply-To: <20001215210136.C62048@cicely5.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Dec 2000, Bernd Walter wrote: > On Thu, Dec 14, 2000 at 10:29:38PM +0100, G=E9rard Roudier wrote: > >=20 > >=20 > > On Thu, 14 Dec 2000, Andrew Gallatin wrote: > >=20 > > > John Baldwin writes: > > > >=20 > > > > Sounds like lost interrupts. Possibly the interrupt isn't being e= nabled > > > > properly after the ithread finishes running the handler. > > >=20 > > > Maybe it is time to accept defeat on squelching interrupts at their s= ource=20 > > > and leave the IPL raised until the handler is run? > >=20 > > I am not an arch. guy and I will be fixed by jhb for sure :). Thanks by > > advance Jhon for teaching me. :) > >=20 > > My understanding is that Alpha is actually IPL based and masking using > > actual level will kill most advantages if threading interrupts, at leas= t > > for level sensitive. My probably false understanding let me think that > > result will be increase of interrupt latency without any gain in anythi= ng > > by threading interrupt handlers. >=20 > 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. Using mutexes instead or spinlocks is probably some means for the goal of scaling up better on mult' CPUs SMP machines. I am just afraid that such an hypothetical better scaling up for 0.0...01% machines may poorly scale down to 99,9999...% of usual machines. I just hope I am plain wrong on this point. > 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. >=20 > But I'm far away from being capable of implementing this. There is nothing complex here, at least in theory. Semaphores with P and V primitives have been invented about 25+ years ago or more by Mr Djiskra (or some name like this) IIRC, and I remember using similar primitives 20 years ago. But the original UNIX kernel, invented on some PDP 6 or 7 machine, probably started with the `=E0 la DEC' spl/ipl synchronisation way, that only makes relevance on single processor machine in my opinion. > 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. >=20 > Another point is that there are lots of MBs in tsunami_intr_enable/disabl= e > especialy the dups are questionable - what's the reason not trusting a > single one? Several may be needed. Will have a look at this when I will have time for. Btw, I donnot seem to see interrupt disable/enable things in the official UNIX PAL code (Btw, the NT one has such verbs). Looks like a not regular use of Alpha hardware, and we probably must be very careful when doing so. > But I can't see where writing to hardware is enshured - are the registers > marked non-cacheable - but then why an mb? Alpha does not guarantee any implicit barrier. Programmer is required to insert all appropriate barriers. Cachable or not cachable does not matter. > 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. G=E9rard. 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?Pine.LNX.4.10.10012152037330.1578-100000>