From owner-freebsd-current@FreeBSD.ORG Thu May 6 01:47:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF36916A4CE; Thu, 6 May 2004 01:47:46 -0700 (PDT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2BF243D54; Thu, 6 May 2004 01:47:43 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i468lg4u009673; Thu, 6 May 2004 18:47:42 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i468leI2019476; Thu, 6 May 2004 18:47:41 +1000 Date: Thu, 6 May 2004 18:47:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20040506180456.J19447@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: Gerrit Nagelhout Subject: RE: 4.7 vs 5.2.1 SMP/UP bridging performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 08:47:46 -0000 On Wed, 5 May 2004, Robert Watson wrote: > The reason to run with these patches is that, without them, it's not safe > to run without Giant over the lower half of the network stack, so all the > network interrupt threads are running with Giant otherwise. What does this particular finer grained locking do for the number of locks. Nothing good I fear. > Also, in that > patchset, network processing to completion runs in the ithread rather than > the netisr, so you get lower latency and more parallelism even for > bridging. Doesn't it give less parallelism, and higher latency for other interrupts, but lower latency for this interrupt of course? > Another known issue is the latency from interrupt generation to interrupt > task execution in the interrupt thread. Especially with the current bugs: - interrupt thread execution is often or always deferred until the running thread gives up control or returns to userland, and all netisr and other. This bug has been active since last November. Before then the indefinite deferral only happened occasionally. - netisr and most other SWI priorities are backwards relative to softclock's priority. This bug seems to have been active since the first version of SMPng. Bruce