Re: [9fans] odd out-of-memory behavior

["Russ Cox" <rsc@swtch.com>]

> 311954: fs killed: out of memory
> out of physical memory; no swap configured
> 311954: fs killed: out of memory
> out of physical memory; no swap configured
> 311954: fs killed: out of memory
>
> there's a sleep of 5 seconds after killbig
> is called.  so, though it's hard to imagine,
> it must be taking 100s to clean up this process.

/sys/src/9/port/proc.c:/^killbig marks the process
to be killed, but if it can't acquire the lock on that
process's segments, the memory is not actually
freed immediately:

	kp->procctl = Proc_exitbig;
	for(i = 0; i < NSEG; i++) {
		s = kp->seg[i];
		if(s != 0 && canqlock(&s->lk)) {
			mfreeseg(s, s->base, (s->top - s->base)/BY2PG);
			qunlock(&s->lk);
		}
	}

Perhaps another upas/fs proc sharing the same
segment is holding the segment lock and
blocking on something else.

If you can make it happen again, you could try
to run

	acid -k -l kernel 1 /386/9pccpu  # or your kernel image
	stacks()

though of course without any memory it's going to
be hard to start acid.  You might be able to pull it off
if you cpu somewhere else, bind /mnt/term/proc /proc,
and then start acid there before you run the machine
out of memory.  As long as the exportfs serving /mnt/term
doesn't need any new memory pages, it should be able
to serve /proc well enough to the remote acid.

Russ