From owner-freebsd-hackers Mon Jun 29 20:58:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA21051 for freebsd-hackers-outgoing; Mon, 29 Jun 1998 20:58:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA21037 for ; Mon, 29 Jun 1998 20:58:36 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d83.syd2.zeta.org.au [203.26.11.83]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA15022 for ; Tue, 30 Jun 1998 13:58:30 +1000 Received: (qmail 25005 invoked by uid 1000); 30 Jun 1998 03:39:00 -0000 Message-ID: <19980630133900.A24973@reilly.home> Date: Tue, 30 Jun 1998 13:39:00 +1000 From: Andrew Reilly To: Jamie Bowden , "Ron G. Minnich" Cc: hackers@FreeBSD.ORG Subject: Re: I2O References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Jamie Bowden on Mon, Jun 29, 1998 at 03:18:17PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 29, 1998 at 03:18:17PM -0400, Jamie Bowden wrote: > On Mon, 29 Jun 1998, Ron G. Minnich wrote: > > > I2O will be a footnote in a year or so. After that, it will be forgotten > > and in 10 years someone else will reinvent the idea and learn the hard > > way why it is a bad one (as I2O is itself a reinvention of old, bad ideas). > > Why is offloading IO a bad idea? Offloading video and 3D rendering work > well, it's what drives 3dfx and it's competitors. Or am I missing > something? My basic understanding of I2O is using a subprocessor to > handle all IO, thus freeing up the main processor from doing things like > waiting on interrupts and the like. I suspect that the "wheel of reincarnation" has something to say about this. The 3D rendering boards are doing a specific operation that happens to be very popular at the moment, which is keeping it alive. It's never going to be as popular as general purpose processors, though, so they will eventually overtake the special purpose 3D engines, and you'll have dumb(ish) frame buffers again. That way you get to keep your textures and geometry models in main memory, which is so much faster...(by then). Why would you want to spend money on another processor, memory subsystem, and so on, for a processor that can't (doesn't) run FreeBSD? You're better off building a multi-processor system that does. That's why SMP systems are much more popular now than the multi-processors that kept one CPU for the operating system, that came before. Of course, the reason that the wheel of reincarnation is there at all is that it's easier to attack each problem with a specific solution, as it arises, than it is to re-orient the general purpose solution as required. So you get blips of non-generality, while the general purpose solution figures out what to do. In this case, the problem that I2O is solving is the poor interrupt performance of the current general purpose processors, and the poor real-time performance of the current operating systems. There are existence proofs that neither of these faults is insurmountable (vis ARM, i960 etc; QNX, VxWorks, others..), so one can assume that the general purpose solution is going to steamroller the special-purpose one pretty quickly, unless other factors (political, rather than technical) get in the way. -- Andrew "The steady state of disks is full." -- Ken Thompson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message