Date: Thu, 20 Jun 2002 22:54:50 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: 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: <20020620225450.A38506@unixdaemons.com> In-Reply-To: <3D128E50.CC2E0387@mindspring.com>; from tlambert2@mindspring.com on Thu, Jun 20, 2002 at 07:24:16PM -0700 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, 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 :-). [...] > 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 That's funny. I brought up the idea of processing network interrupts to completion at the developer summit and Jeffrey Hsu pointed out quite the opposite. He mentionned, and with very good reason, that the longer you spend running the stack like that as soon as you take the interrupt, the easier you'll be in livelock when you start taking a lot of interrupts (it was along those lines (I appologize, Jeffrey, if I didn't quote you exactly here)). If we have a pool of threads available to run the stack, though, perhaps we could do a sort of hybridized thing where we take the interrupt and switch to one of our available threads to process the packet, but once we hit the stack layer, re-enable the source and keep running. That way we could take another interrupt from the same source and we'll at most end up scheduling N threads (where N <= #cpus). To make matters worse, we could even decide to not re-enable the source when we switch to the N'th (final) thread - this way, we may end up preventing total livelock should we hit a storm. Once we run out of threads, we just set the need_service bit and return. Perhaps we'll find that the optimal number of threads to schedule at most at any given time will be something like N = #cpus/2. In any case, this is at best speculative and totally theoretical and we really can't argue these issues right now and expect to reach the correct solution. Once the network stuff is further done, we'll be able to revisit this. Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@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?20020620225450.A38506>