Date: Thu, 24 Apr 2003 23:13:06 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Aniruddha Bohra <bohra@cs.rutgers.edu> Cc: freebsd-smp@freebsd.org Subject: Re: Question about interrupt threads Message-ID: <20030424230034.T25199@gamplex.bde.org> In-Reply-To: <3EA72A0B.5000606@cs.rutgers.edu> References: <3EA5E29F.9000801@cs.rutgers.edu> <20030423214814.P21296@gamplex.bde.org> <3EA72A0B.5000606@cs.rutgers.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Apr 2003, Aniruddha Bohra wrote: > Provided all ISRs spin on their locks, and do not sleep, we can assume the > critical section to be small enough as to not allow interrupt handlers > on other CPUs > to spin for a long time. Then, the problem does go away. Or am I missing > something important here ? Understandably while there is a GIANT lock > protecting ISRs, this is not possible. We can't assume that. There are still lots of interrupt handlers and hardware of dubious quality that take a remarkably long time to handle interrupts. Timeout routines can take several msec, and it can take several msec to reach the timeout dispatcher (softclock). Timeouts are software interrupts, but software interrupts are not very different from hardware ones in FreeBSD and it is hardware interrupts that delay softclock (the main cause that I've seen here is VTY switching -- syscons still uses busy waiting for setting the LEDs). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030424230034.T25199>