On 08/06/2014 18:56, Bakul Shah wrote:
On Sun, 08 Jun 2014 03:56:24 EDT erik quanstrom wrote:
- try this out on a small scale before you commit to it, as I
suspect you'll run into various limits and may be bugs. Do
report what you discover.
- performance will likely be poor. For better pe
On Mon Jun 9 23:55:00 EDT 2014, cinap_len...@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 re
> 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.
The one place where I can imagine lots of cache hits is when running
parallel mk jobs
no. my attachimage() compares qid + mountid (which is unique) and
reattaches the passed in channel if image->c was nil. when
a porcess exits, the segments are released, decrementing ref of
the pages and the images. the image has an additional field pgref where
it counts the number of page referenc
On Tue Jun 10 09:58:18 EDT 2014, st...@quintile.net wrote:
> > 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.
>
> The one place w
