From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10807020717j6b73dcadwa6ddc069c1bd119b@mail.gmail.com> Date: Wed, 2 Jul 2008 07:17:45 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13426df10807020630s68ec3846l793f7fec96699947@mail.gmail.com> Subject: Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar Topicbox-Message-UUID: d5e3313e-ead3-11e9-9d60-3106f5b1d025 On Wed, Jul 2, 2008 at 6:40 AM, erik quanstrom wrote: >> Here's a bigger question, now that I've read the paper and briefly >> scanned the code. Do you have some thoughts on the long term ability >> of vx32 to get close to unity performance on a system (like Plan 9) >> with a high rate of context switches between file server processes >> (you allude ot this cost in the paper). It's an ideal terminal right >> now. I don't see a need to use drawterm any more. >> >> But running fossil and venti, it's got a ways to go in terms of >> performance (i.e. mk clean in /sys/src/9/pc takes ~60 seconds). > > import(1)'ed files, host files and ramfs files are similarly slow. I don't want to turn this into a "let's pile onto vx" discussion, just more a discussion of how far we can go with the approach performance-wise. Some of the issues are well brought out in the paper, I'm just rolling the questions around in my sleep-deprived mental state. I'm currently just trying to figure out how to (re)package THX to make it easier for people to use, and which virtualization system to use ... ron