On Wed, Aug 08, 2007 at 10:13:41AM -0700, ron minnich wrote:
On a more controversial note, we had a good discussion on scaling limitations of the current system call interface and how a new type of asynchrony might be introduced. One idea was that one could build on the current rendezvous interface so that it could accept a closure (or context). Then the user process would fire up a bunch of threads, most of which would hang out in the rendezvous. For non-blocking I/O, a process would kick off the system call, but the system call would return immediately after queueing up the I/O and the actual return would wake up one of the threads waiting in the rendezvous. This was just one idea, but it's interesting. The bigger question, for me, remains: how would we extend the system call interface to handle, e.g., 100,000 connections to "something(s)" without losing the essence of Plan 9? This question is not academic -- the BG/P machines are planned to have 256K CPUs, and we plan to run on them. We could just claim that firing up an ioproc for each file descriptor would work, but I've never been comfortable with that model -- for one thing, I can tell you from experience that seeing even 20,000 procs in a ps is fairly confusing. We could punt and just say "9p everything", but as David pointed out, that leaves us with a fairly chaotic universe -- we lose a lot of the ordering and such that the kernel gives us now via the basic open/read/write/close interface.
A student, advised by Russ, wrote a paper on async IO on Plan 9 without kernel modifications. The basic idea, as I understand it, is to use the inherent asynchrony of 9P, and access files via the kernel's exportfs interface. The concept could easily be wrapped into a simple userspace aio lib. I prefer the idea to modifying the kernel, but I'm not sure that the overhead would be acceptable to all applications.
-- Kris Maglione The severity of an itch is inversely proportional to the reach.
