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

unfortunately or fortunately this is a rare problem.
hopefully the caching upas will mature faster than
our mailboxes grow.

thanks for re-pointing out the acid tricks.  i shall
lay a trap.  but in the interest of covering the careful
thought bit ...

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

how would that happen?  upas/fs -p doesn't fork.
(it's being run from imap4d.)

is there some other reason that segments would
be shared?

i originally thought someone else might be sitting
on the shared segments, but i couldn't explain how
that might be happening.  i also thought the purpose
of this loop was to hunt down relatives sharing memory
with killbig's vic:

	for(p = procalloc.arena; p < ep; p++) {
		if(p->state == Dead || p->kp)
			continue;
		if(p != kp && p->seg[BSEG] && p->seg[BSEG] == kp->seg[BSEG])
			p->procctl = Proc_exitbig;
	}

so much for the "careful" thought.  what am i missing?

- erik