Date: Wed, 12 Oct 2005 21:36:01 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: net@FreeBSD.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <20051012212915.E66014@fledge.watson.org> In-Reply-To: <17229.29164.891534.200216@grasshopper.cs.duke.edu> References: <20051008143854.B84936@fledge.watson.org> <17229.29164.891534.200216@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Oct 2005, Andrew Gallatin wrote: > Speaking of net.isr, is there any reason why if_simloop() calls > netisr_queue() rather than netisr_dispatch()? Yes -- it's basically to prevent recursion for loopback traffic, which can result in both lock orders and general concerns regarding reentrance. To be specific: if you send a packet on a loopback TCP socket, it gets processes asynchronously in the netisr rather than immediately walking back into the TCP code again. Right now WITNESS would warn about this, but there were also quite bad things that could happen before we did the locking work -- for example, when connections are torn down. It also avoids Really Deep Stacks. At some point, someone needs to look at some scheduler traces and make sure we're not seeing anything silly like the following: - Socket output delivers to TCP, which outputs to loopback, which inserts the packet into the netisr queue, waking up the netisr thread. - The netisr, running at a lower priority, preempts the running thread, which may still hold TCP locks, causing it to hit to the lock and yield to the user thread, which will now run briefly with depressed priority due to priority propagation. I.e., it may be that we're taking untimely context switches on UP for loopback traffic. I've not actually seen this, but we should make sure we're not seeing it. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051012212915.E66014>