From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <775b8d190709062109o1c0a64b8y55ceb79e95083ecb@mail.gmail.com>
Date: Fri,  7 Sep 2007 14:09:44 +1000
From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] plan 9 overcommits memory?
In-Reply-To: <1189134549.6197.2.camel@ginkgo>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <13426df10709061238l1e081fel101928310c9db13c@mail.gmail.com>
	<1189134549.6197.2.camel@ginkgo>
Topicbox-Message-UUID: ba336158-ead2-11e9-9d60-3106f5b1d025

this thread is now twice as big as the swap and proc code.
is it really that much fun to do research this way?
yes, it has been done.  no, my current work has nothing
to do with this issue.

someone written a line of relevant code during this "discussion"?

brucee

On 9/7/07, Roman Shaposhnik <rvs@sun.com> wrote:
> On Thu, 2007-09-06 at 12:38 -0700, ron minnich wrote:
> > On 9/6/07, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> >
> > > I can't imagine that either of these uses are nearly compelling enough
> > > to open this can of worms....  Has anyone truly felt confined by Plan
> > > 9's fork+exec model?
> >
> > yes, because exec takes a pathname. that's a pull model. That is
> > pretty awful in a large machine. Define awful: ok, it's the difference
> > between startup times of 3+ minutes, 400 nodes, vs. 3 seconds. That's
> > awful.
> >
> > it's why we started doing xcpu in the first place: push the binary to
> > a ram disk, then at least xcpu is pulling from a local place, not a
> > network. But xcpu was a compromise: I really wanted to do a process
> > creation device.
>
>  Exposing an interface for process manipulation to userspace would be
> quite cool. Any prototypes on Plan9 so far?
>
> Thanks,
> Roman.
>
>