Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Mar 95 14:48:32 MST
From:      terry@cs.weber.edu (Terry Lambert)
To:        davidg@Root.COM
Cc:        current@FreeBSD.org
Subject:   Re: "Text file busy" with program not running anymore?
Message-ID:  <9503062148.AA19933@cs.weber.edu>
In-Reply-To: <199503061842.KAA02233@corbin.Root.COM> from "David Greenman" at Mar 6, 95 10:42:37 am

next in thread | previous in thread | raw e-mail | index | archive | help
> >Luckily, the working set limitations mean that this will probably take
> >as effectively long as "until you unmount that disk or reboot".
> >
> >Isn't that true?
> 
>    No, the behavior is controlled by the limit on cached objects (not on the
> pages associated with them). I've lost the context of what we're talking about
> here. Any file that is currently mapped into a process that is subsequantly
> deleted will continue to consume space until all mappers of it have unmapped
> it (or in other words, until all references to it have been dropped). This is
> the same behavior as you would expect if you had the file open when someone
> else deleted it.

Working set quotas on a unified cache mean that it is much more likely
to leave non-buffer data in cache is what I meant.

This would increase the persistance of objects whose only path for
invalidation was falling off the LRU.


The problem boils down to the cache being counted as a reference for
the purposes of LRU and VTEXT, which boild down to a problem in the
cache architecture.


I think implementing the persistance changes from the 92 Usenix paper
neglects the effect a cache unification will have, and that perhaps
the persistance changes are no longer a good idea.

I will dig up paper references tonight when I get home.

Unless there is a preference for non-dirty pages to be pulled from
swap instead of from an image, I think the persistance changes will
do nothing excpet cause thrashing once the cache is >80% full.

Even with a preference for swap, there needs to be some kind of
low and high watermarking of cache usage by purpose.  I don't
know if this would be antithetical to the cache unification, or if
you could still call it unified in good faith afterwards.

The main problem with unification is that you combine two things
which are succeptable to locality of reference, but which are
jointly not equally succeptable.

I think there are some deeper issues here, one of which is that some
of the assumptions made in the VM design pre-unification depend on
behaviours which may no longer be present.

Like I said, I'll have to dig out references to comment intelligently.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503062148.AA19933>