Date: Wed, 23 Apr 2003 12:20:49 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Aniruddha Bohra <bohra@cs.rutgers.edu> Cc: freebsd-questions@FreeBSD.org Subject: Re: Interrupt threads Message-ID: <20030423025049.GG49736@wantadilla.lemis.com> In-Reply-To: <3EA5B8CF.7080803@cs.rutgers.edu> References: <3EA5B8CF.7080803@cs.rutgers.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--0qt3EE9wi45a2ZFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 22 April 2003 at 17:49:03 -0400, Aniruddha Bohra wrote: > Hello > Reading the implementation of interrupt handling on i386, > and reading Greg Lehey's Usenix paper on FreeBSD 5.0 SMP > implementation, I understand that interrupt handling is done in > process context. This is needed partly to support sleeping while > handling the interrupt because GIANT needs to be locked and > a sleep is possible there. > > My question is after all subsystems that lock giant are made > INTR_MPSAFE will the implementation go back to non-process > context interrupt handling (as in older versions) ? No. INTR_MPSAFE means that the ISRs use their own locking scheme. They can still sleep. > Moreover, will the locking be per-IRQ or there will be a global > IRQ lock for ensuring atomic access to the ISRs ? No. The locks will be finer grained, generally per device, not per IRQ. > Finally why do we need to create a kernel thread for each IRQ - > why can't one kernel thread handle all the IRQs ? If the kernel thread sleeps on one lock, everything would stop. Even if you accept that you're only processing one interrupt at a time, I can't think of a way to do this without instant deadlock. That's the whole point of having the threads in the first place. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers --0qt3EE9wi45a2ZFX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+pf+JIubykFB6QiMRAiNbAJ0T/R+xBKahiGf3r9fTapsT6g+xCwCfX4Lk HreUn2gNEB2hTl7X0XFY33Y= =ge4F -----END PGP SIGNATURE----- --0qt3EE9wi45a2ZFX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030423025049.GG49736>