From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 8 Aug 2007 13:27:17 -0400 From: Kris Maglione To: 9fans@cse.psu.edu Subject: Re: [9fans] Bay Area Plan 9 Users Group Meeting (August '07) Message-ID: <20070808172717.GD68665@kris.home> References: <8ccc8ba40708011355v1ff80d1eu481456f50e0e05cc@mail.gmail.com> <3CEED615-AF39-4907-91EF-6F5A5FF3CC86@tinker.com> <3e1162e60708071856r3651a753k58963e306225abbd@mail.gmail.com> <775b8d190708080426h58af05d5w58ca4aacd57efe9c@mail.gmail.com> <13426df10708081013t7e4d0072g21f154bca5c94336@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <13426df10708081013t7e4d0072g21f154bca5c94336@mail.gmail.com> User-Agent: Mutt/1.5.15 (2007-04-06) Topicbox-Message-UUID: a01a0ec0-ead2-11e9-9d60-3106f5b1d025 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.