From owner-freebsd-arch Tue Jun 25 2:23:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 997A737B400; Tue, 25 Jun 2002 02:23:14 -0700 (PDT) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.3+3.5Wbeta/3.7W-rina.r-Nankai-Koya) with ESMTP id g5P9NA3i080067 ; Tue, 25 Jun 2002 18:23:10 +0900 (JST) Message-Id: <200206250923.g5P9NA3i080067@rina.r.dl.itc.u-tokyo.ac.jp> Date: Tue, 25 Jun 2002 18:23:10 +0900 From: Seigo Tanimura To: Bosko Milekic Cc: Terry Lambert , Robert Watson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts In-Reply-To: <20020620225450.A38506@unixdaemons.com> References: <3D128E50.CC2E0387@mindspring.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Jun 2002 22:54:50 -0400, Bosko Milekic said: bmilekic> On Thu, Jun 20, 2002 at 07:24:16PM -0700, Terry Lambert wrote: >> Robert Watson wrote: >> > Unfortunately, I'm probably not really qualified to talk much about the >> > swi stuff. But I can say I'd really like to have multiple netisr threads >> > once the lock pushdown on IPv4 is more done :-). bmilekic> [...] >> I can't understand the fascination with NETISR, however. It should >> not exist in the first place. >> >> If any one doubts this, they really need to contact Van Jacobsen; >> as Archie Cobbs, since he works at the same company as Van, if >> you don't have contact information for Van yourself. >> >> -- Terry bmilekic> That's funny. I brought up the idea of processing network interrupts bmilekic> to completion at the developer summit and Jeffrey Hsu bmilekic> pointed out quite the opposite. He mentionned, and with very good bmilekic> reason, that the longer you spend running the stack like that as soon as bmilekic> you take the interrupt, the easier you'll be in livelock when you start bmilekic> taking a lot of interrupts (it was along those lines (I appologize, bmilekic> Jeffrey, if I didn't quote you exactly here)). If we have a pool of bmilekic> threads available to run the stack, though, perhaps we could do a sort bmilekic> of hybridized thing where we take the interrupt and switch to one of our bmilekic> available threads to process the packet, but once we hit the stack bmilekic> layer, re-enable the source and keep running. That way we could take bmilekic> another interrupt from the same source and we'll at most end up bmilekic> scheduling N threads (where N <= #cpus). To make matters worse, we could bmilekic> even decide to not re-enable the source when we switch to the N'th bmilekic> (final) thread - this way, we may end up preventing total livelock bmilekic> should we hit a storm. Once we run out of threads, we just set bmilekic> the need_service bit and return. Perhaps we'll find that the bmilekic> optimal number of threads to schedule at most at any given time will be bmilekic> something like N = #cpus/2. In any case, this is at best speculative bmilekic> and totally theoretical and we really can't argue these issues right now bmilekic> and expect to reach the correct solution. Running multiple interrupt threads is just one way to improve the MLFRR (in light of Mogul's paper) of a host. We can use that with polling or elimination of software interrupt. One merit of running multiple interrupt threads would be that we can apply it to a subsystem other than the network stack. A high-speed serial device (USB, Firewire, etc.) may benefit from this approach as well. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message