Thread 9 (Thread -1758905456 (LWP 2695)):
#0 0xb7f78424 in __kernel_vsyscall ()
#1 0x4e6f7a43 in poll () from /lib/libc.so.6
#2 0x4117fa99 in ?? () from /usr/lib/libX11.so.6
#3 0x4117fe7f in _XRead () from /usr/lib/libX11.so.6
#4 0x411816bb in _XReadEvents () from /usr/lib/libX11.so.6
#5 0x4116a7ab in XNextEvent () from /usr/lib/libX11.so.6
#6 0x080a19e9 in _xproc (v=0x0) at 9vx/x11/x11-kernel.c:141
#7 0x08056f7b in linkproc () at 9vx/trap.c:484
#8 0x00000000 in ?? ()

Thread 8 (Thread -1768612976 (LWP 2696)):
#0 0x4e701723 in __call_pselect6 () from /lib/libc.so.6
#1 0x4e6fa723 in pselect () from /lib/libc.so.6
#2 0x0805647a in timerkproc (v=0x0) at 9vx/time.c:187
#3 0x08056f7b in linkproc () at 9vx/trap.c:484
#4 0x00000000 in ?? ()

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

first. Did that happen? I've done a lot without
running out of memory (including building gs)
so it wouldn't be my first guess, unless that print
happened, preferably very close to when acme died.

Russ

On Wed, Jul 2, 2008 at 6:16 AM, Russ Cox swtch.com> wrote:

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).

import(1)'ed files, host files and ramfs files are similarly slow.
this is no benchmark, and it's a bit questionable because it's
right on the limit of time's measurement, but it does reflect
a lag i see that i don't see in drawterm:

drawterm (the file is 4368 bytes),

0.00u 0.00s 0.00r cat usps.jpg
9vx

0.00u 0.00s 0.01r cat usps.jpg

On Wed, Jul 2, 2008 at 6:40 AM, erik quanstrom quanstro.net> wrote:

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.

You can run acid inside 9vx to get a stack trace of the
broken processes. Maybe a pattern will emerge.

Russ

There's not likely anything in the guts of vx32 that hasn't been done
before. What's new is the fact that we managed to package it up in
a way that runs on a variety of out-of-the-box OS'es with
neither kernel modifications nor special privileges on any x86.
That portability is key to being able to deploy interesting apps,
like 9vx.

why can only one thread run vx32?

- erik

i think i found part of the answer just now. see the comment above
9vx/main.c:^setsigsegv

9vx requires that the page fault handler runs on an alternate stack
during vx32 ("user") execution and on the kernel stack during
kernel execution. That bit--whether or not to run the signal handler
on the pthread's alternate signal stack--is part of the struct sigaction
defining the signal-handling behavior, which is shared by all
pthreads in the process, not per-pthread. 9vx arranges that the
global bit is correct for all pthreads by only allowing one of the
pthreads--cpu0--to page fault. The others, which run supporting
kprocs, arrange never to fault. When user i/o is moved off cpu0
to the supporting kprocs, the i/o has to be done into fault-free
kernel buffers and then copied back into user space on cpu0.