Date: Sun, 6 Oct 2002 21:56:26 -0700 (PDT) From: Nate Lawson <nate@root.org> To: freebsd-arch@FreeBSD.ORG Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Running independent kernel instances on dual-Xeon/E7500 system Message-ID: <Pine.BSF.4.21.0210062141050.5730-100000@root.org> In-Reply-To: <3DA10949.218488B9@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Oct 2002, Terry Lambert wrote: > Nate Lawson wrote: > > My dismissiveness was due to anticipating the direction this was going, > > which is nicely shown by the response below. In short, dedicated > > processors for IO were used in the minicomputer days but are wasteful > > nowadays when you have lightweight interrupts and/or polling when > > appropriate. > > Yet, I keep running into employers who want to pay people to do > exactly that, particularly for offloading network processing to > one processor, and running applications on the other. Been there, hence the touchiness. > And then there's the Tigon II firmware rewrite for FreeBSD, to > offload interrupt and copy processing. And CGD's work for Sibytes > (NetBSD 64bit MIPS-based network coprocessor board) doing just that > got the company sold to Broadcom for what, $700M? > > 8-). I agree that when there are spare cycles available on the _device_'s processor it should be doing more work. But that's very different from dedicating a processor that could otherwise be doing useful work (given a well-written SMP-aware OS of course). > > If your scheduler sucks, fix it. If a device needs extra processing > > equivalent to another N Ghz CPU, the vendor will add silicon. The "S" in > > SMP is for symmetric, lest we forget. > > People keep saying that, and then keep not running interrupts in > virtual wire mode, so that their delivery is "S" as in "symmetric"... > ;^). > > Actually, NT proved that wiring particular interrupts to particular > processors was the way to go -- that was one of the things they did > to beat the Linux numbers in both the Netcraft and Ziff-Davis > benchmarks... perfect symmetry isn't all that it's promised. > > -- Terry I'm not sure that breaks my definition of symmetric since that sounds like they were just setting the processor affinity per interrupt. ;-) I agree that for a given fixed workload profile, it may make sense to build a single-purpose device out of off-the-shelf parts. But most of the time, the decision to go that way is the result of a knee-jerk reaction that "I'm a Real Programmer and I want bare metal because it's faster". I believe that mostly results in slower systems because the workload always changes out from under the designer's assumptions. Hence we get more real benefits from versatile things like branch prediction, register scoreboarding, etc. that make their decisions at runtime instead of chalkboard time. Here's an archived email by VJ that seems amazingly relevant, even today: http://www.root.org/ip-development/news/vanj.88jul20.txt -Nate 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?Pine.BSF.4.21.0210062141050.5730-100000>