Re: [9fans] Bay Area Plan 9 Users Group Meeting (August '07)

[Kris Maglione <bsdaemon@comcast.net>]

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.