Date: Tue, 25 Jun 2002 18:23:10 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Terry Lambert <tlambert2@mindspring.com>, Robert Watson <rwatson@FreeBSD.ORG>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <200206250923.g5P9NA3i080067@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: <20020620225450.A38506@unixdaemons.com> References: <Pine.NEB.3.96L.1020620141850.18867E-100000@fledge.watson.org> <3D128E50.CC2E0387@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Jun 2002 22:54:50 -0400, Bosko Milekic <bmilekic@unixdaemons.com> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206250923.g5P9NA3i080067>