On Wed, Jul 2, 2008 at 6:16 AM, Russ Cox <[EMAIL PROTECTED]> wrote: >> Is this another out of memory? This >> happened on a mk clean on kernel source > > It would not surprise me if the new pager (post-0.12) > caused the problem, but in order for that > to happen the kernel would have had to print > > uh oh. someone woke the pager
That I did not see. Just the no segment error. 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). At this point, the fastest virtualization system for kernel mk on my x60 is still xen, at 12 seconds. I had expected lguest to beat that, but it never has. There are claims that kvm is running at close to unity, but that's probably for linux -- I have not tested kvm lately with plan 9. At the same time, in terms of effort, vx32 is far easier to run than the alternatives, and hence is superior in the long term as a way to get plan 9 into people's hands. Also, opteron. lguest on opteron should be ready soonish. But vx32 is still a highly desirable alternative. Do you have thoughts on how to sandbox on opteron, where you don't have the segment registers? Could you use mctl to sandbox and then filter mmap system calls from the sandboxed code to make sure the sandbox can not be escaped? enough rambling. I'm in a west coast brain on the east coast, still not awake at this point. Thanks ron
