From owner-freebsd-alpha Wed Jan 3 2:11:42 2001 From owner-freebsd-alpha@FreeBSD.ORG Wed Jan 3 02:11:40 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 6800037B400; Wed, 3 Jan 2001 02:11:39 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 14DktN-000C4n-0Y; Wed, 3 Jan 2001 10:11:37 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA63503; Wed, 3 Jan 2001 10:13:50 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 3 Jan 2001 10:13:23 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: alpha@freebsd.org Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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