From owner-freebsd-arch Thu Jun 20 11:33: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 7A49837B40A; Thu, 20 Jun 2002 11:33:04 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5KIUkB23173; Thu, 20 Jun 2002 14:30:46 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 20 Jun 2002 14:30:46 -0400 From: Bosko Milekic To: Robert Watson Cc: Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020620143046.A23114@unixdaemons.com> References: <200206201035.g5KAZ53i029301@rina.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@FreeBSD.ORG on Thu, Jun 20, 2002 at 02:19:23PM -0400 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, Jun 20, 2002 at 02:19:23PM -0400, 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 :-). As I hinted, I think that this is a reasonable idea. However, we may end up observing that, for certain cases, particularly those such as network device hardware interrupts (which essentially just queue the packet and schedule the software interrupt thread), it is better to wait until the handler is done running and merely re-service it because the second thread is likely to contend with the first anyway, and because that contention may lead to ping-ponging between CPU caches. We may end up seeing that for netisr type stuff, it is better to have multiple threads running in parallel. We may see, also, for example, that it is better to have a maximum of N/m threads running in parallel for an N cpu system (where m < N). I would like to keep the thread pool code around, and possibly see it committed soon, but not have it take effect in all cases just yet, particularly not in the hardware interrupt cases, at least not right now. > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories 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