From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue, 10 Jun 2014 08:58:10 -0400
To: 9fans@9fans.net
Message-ID: <8a74e4235d48b56ef9fd8eee42c95c74@brasstown.quanstro.net>
In-Reply-To: <fbef63d89c190b62f5347ce814a745ff@felloff.net>
References: <fbef63d89c190b62f5347ce814a745ff@felloff.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] duppage
Topicbox-Message-UUID: f95181b6-ead8-11e9-9d60-3106f5b1d025

On Mon Jun  9 23:55:00 EDT 2014, cinap_lenrek@felloff.net wrote:
> while you'r at it. take a look at 9front imageattach() code.
> it allows the chan attached to the image to be released when the
> image is not in use. this avoids all these chans and mounts
> being kept arround until the image is reclaimed. the problem
> is worked arround in iostats by killing the filesystem process
> once the command exits. you can reproduce by copying a binary
> to a fresh ramfs, executing and then unmount. ramfs will stay
> arround because the image cache still holds onto the binaries
> channel.

i noticed that the private channel free queue was dropped in favor
of ccloseq.  good idea.

if i understand correctly, there's an other hand to this solution.
if a process exits and is then run again, it will always be re-read
from storage.  (since channel comparisons factor in to finding
an image.)  only if the lifetime overlaps will the cached image be
used.

i think it would make more sense to simply reclaim pages with
p->image != nil quicker, if you don't like the current set up.

- erik