Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar things this morning.

["ron minnich" <rminnich@gmail.com>]

On Wed, Jul 2, 2008 at 6:16 AM, Russ Cox <rsc@swtch.com> 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