From owner-freebsd-current Mon Mar 6 13:55:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA19493 for current-outgoing; Mon, 6 Mar 1995 13:55:07 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA19487 for ; Mon, 6 Mar 1995 13:55:03 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19933; Mon, 6 Mar 95 14:48:33 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503062148.AA19933@cs.weber.edu> Subject: Re: "Text file busy" with program not running anymore? To: davidg@Root.COM Date: Mon, 6 Mar 95 14:48:32 MST Cc: current@FreeBSD.org In-Reply-To: <199503061842.KAA02233@corbin.Root.COM> from "David Greenman" at Mar 6, 95 10:42:37 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > >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.