From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10709061238l1e081fel101928310c9db13c@mail.gmail.com> Date: Thu, 6 Sep 2007 12:38:00 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] plan 9 overcommits memory? In-Reply-To: <7871fcf50709061015u3354f721ga0bddab13a3ed49@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DDB9AD.DF4673BE@null.net> <46DEE273.243B2292@null.net> <7871fcf50709061015u3354f721ga0bddab13a3ed49@mail.gmail.com> Topicbox-Message-UUID: b9ae786c-ead2-11e9-9d60-3106f5b1d025 On 9/6/07, Joel C. Salomon 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. ron