From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: Re: [9fans] odd out-of-memory behavior
From: "Russ Cox" <rsc@swtch.com>
Date: Fri, 25 Jul 2008 14:09:23 -0400
In-Reply-To: <affb36fb79a62b76bfcbcbaea0a78eea@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080725180709.0B0441E8C1C@holo.morphisms.net>
Topicbox-Message-UUID: f1093ba2-ead3-11e9-9d60-3106f5b1d025

> 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