Date: Wed, 3 Jan 2001 10:13:23 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@freebsd.org> Cc: alpha@freebsd.org Subject: RE: Interrupt threads Message-ID: <Pine.BSF.4.21.0101031012220.445-100000@salmon.nlsystems.com> In-Reply-To: <XFMail.010102114301.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Jan 2001, John Baldwin wrote: > > On 28-Dec-00 Doug Rabson wrote: > > I started trying to work on changing the interrupt system so that the > > ithread runs with i/o interrupts disabled, which would allow us to remove > > the ugly code which tries to disable the interrupt sources. > > > > Unfortunately I immediately came up against a brick wall - the very first > > interrupt interrupted a proc which owned Giant and the ithread also wanted > > Giant. It tried to block, which switched back to the Giant owner with > > interrupts enabled, causing the interrupt to fire again. > > > > I'm not sure what the right approach to solving this is. Possibly we could > > 'lend' the mutex holder the IPL of the blocking thread in a similar way to > > priority propagation. Another idea is to link thread IPL directly to its > > priority so that when the ithread lends its priority, the mutex owner will > > automagically run with raised IPL. > > I detailed what I think is a way of using IPL to do this in a pair of e-mails > to Drew that Matt was copied on. I'll go dig them up and forward them to here. > However, tying IPL to a process or a mutex is a mistake I think. You can't tie > it to Giant because Giant is going away eventually. You can't tie it to a > process because the first context switch that doesn't switch into the ithread > will cause the interrupt to fire again. Instead, you basically have to futz > with the trapframe in the interrupt handler so it doesn't lower IPL upon > returning from teh interrupt, and don't lower the IPL again until the interrupt > handler completes and the ithread finishes. Interacting properly with ast() on > this makes it a bit more tricky. Let me go dig up my e-mails and forward them > to the list. I've been thinking about this a lot over the last few days and it seems to me that linking IPL directly to the process priority would be a very clean way of dealing with this. It would mean finally fixing and enabling the priority propagation code though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 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.BSF.4.21.0101031012220.445-100000>