Date: Sun, 16 Oct 2005 14:06:32 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@freebsd.org> Cc: Garrett Wollman <wollman@csail.mit.edu>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Andrew Gallatin <gallatin@cs.duke.edu>, net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) Message-ID: <20051016135234.T86712@delplex.bde.org> In-Reply-To: <20051015194738.C66245@fledge.watson.org> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> <17231.50841.442047.622878@grasshopper.cs.duke.edu> <20051015092141.F1403@epsplex.bde.org> <20051015194738.C66245@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Oct 2005, Robert Watson wrote: > On Sat, 15 Oct 2005, Bruce Evans wrote: >> ... However, for netisrs I think it is >> common to process only 1 packet per context switch, at least in the >> loopback case. > > The Mach scheduler allows deferred wakeups to be issued -- "wake up a thread > in the sleep queue -- but when it's convenient" to avoid premature preemtion. > This helps avoid immediate preemption where it's unnecessary and/or > undesirable: specifically, to avoid preemption when the preempting thread > will immediately require a lock held by the signalling thread, as occurs with > the netisr and TCP. Hmm, does it still do that? A year or two, at least the loopback case used to run into itself on Giant, and pushing down giant made things worse (scheduling the netisr would switch immediately because the netisr was "MPSAFE" but then the netisr would immediately block on Giant and switch back, so it took 2 expensive context switches instead of just 1 to get a netisr to do anything). > I've not yet investigated tweaking things, or even a > scheduler trace to see for sure that this is happening, but it wouldn't > surprise me at all if we're seeing extra context switches due to premature or > untimely preemption following wakeup. Probably the problem is largest for latency, especially in benchmarks. Latency benchmarks probably have to start cold, so they have no chance of queue lengths > 1, so there must be a context switch per packet and may be 2. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051016135234.T86712>