Date: Thu, 14 Dec 2000 22:29:38 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: John Baldwin <jhb@FreeBSD.ORG>, Matthew Jacob <mjacob@feral.com>, alpha@FreeBSD.ORG Subject: RE: mutex/ithread jitters? Message-ID: <Pine.LNX.4.10.10012142207190.1637-100000@linux.local> In-Reply-To: <14905.6815.2347.450995@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Dec 2000, Andrew Gallatin wrote: > John Baldwin writes: > >=20 > > Sounds like lost interrupts. Possibly the interrupt isn't being enabl= ed > > properly after the ithread finishes running the handler. >=20 > Maybe it is time to accept defeat on squelching interrupts at their sourc= e=20 > 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. On IA32, we can mask at IO APIC level and EOI in advance, but this looks like odd tinking to me and may-be will just fight with IO APIC optimizations that assume some behaviour of the CPU in optimization heuristics. Anyway tampering the IO APIC may well be slow. (?) Always regarding level-sensitive interrupts, I happen to dream of implementing interrupt handling in 2 separates handlers. - A fast half handler that runs in the "expected by hardware" interrupt context and that gets device status information, clears the device interrupt condition, passes the info to he other half handler.=20 - the other handler may be ithread if it is not fast enough or may=20 contend too much on other resources. (This is not original, indeed :-) ) I read Solaris does thread interrupt handlers. Could it be that Sparc hardware has been specifically tailored for this not to have adverse effects ? 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.10012142207190.1637-100000>