From owner-freebsd-arch Tue Sep 12 4:26:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2CDBE37B422 for ; Tue, 12 Sep 2000 04:26:55 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e8CBQsN21789 for arch@freebsd.org; Tue, 12 Sep 2000 04:26:54 -0700 (PDT) Date: Tue, 12 Sep 2000 04:26:54 -0700 From: Alfred Perlstein To: arch@freebsd.org Subject: what to do with softinterrupts? Message-ID: <20000912042654.L12231@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There's a problem with softinterrupts: we have only one. I'm trying to figure out what to do with the situation because unless I can schedule more than one concurrantly I can't really test much of what I'm working on, there's also making the input path concurrant and responsive. After thinking about it for some time I came up with a solution for network drivers. The idea is to keep several spare interrupt threads available for the network interrupts. Instead of ether_input() figuring out the type of packet and schduling a soft interrupt it will: Swap out its repsonsibility with another spare thread to handle the interface's hardware interrupt Perform a callback to the driver to re-enable interrupts Jump directly into what is now a pseudo-soft-interrupt This will happen as long as it can reserve a spare thread, and we're not pre-empting a softinterrupt running(*) in the same protocol on the same CPU. Otherwise it simply queues and schedules like before. (*) running == not blocked on a mutex, if it's blocked on a mutex we allow another jump from hardware to software to gain concurrancy. When the softinterrupt is complete it will then recheck its input queue for mbufs, if there is none it will return to it's state as an idle interrupt thread making itself free for consumption to service other devices or stacks. From my point of view this will give: better concurrancy, by making the stack less likely to stall because of blocking while accessing potentially locked objects less context switching because there's no need to schedule a soft interrupt unless we are seriously bogged down Poul-Henning Kamp thought that investigating atomic ops and keeping most of the current scheme of things would also work. We'd have to have a softinterrupt bound to each CPU, but as long as they could proceed without blocking we'd probably be ok. The problem I see with this is that it sort of tries to get around the whole interrupt thread idea by going back to non-blocking interrupts instead of taking the advantage (or performance hit) of the threads system we have in place. I'm not dead set on either idea, but I wanted to know what other solutions people could come up with to address this problem, any takers? any existing solutions? thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message