From owner-freebsd-current Mon Mar 6 14:04:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA19672 for current-outgoing; Mon, 6 Mar 1995 14:04: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 OAA19665 for ; Mon, 6 Mar 1995 14:04:03 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19959; Mon, 6 Mar 95 14:57:37 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503062157.AA19959@cs.weber.edu> Subject: Re: more ETXTBSY bugs To: davidg@Root.COM Date: Mon, 6 Mar 95 14:57:36 MST Cc: current@FreeBSD.org In-Reply-To: <199503061853.KAA02254@corbin.Root.COM> from "David Greenman" at Mar 6, 95 10:53:41 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > >A lot of what is "common knowledge about VM" is no longer applicable > >with a unified cache, so this limit might not be as good an idea as > >it seems to be. > > The algorithms are difficult to get right. John has been advocating that > pages involved in file I/O should compete with traditional VM pages. I've > seen reduced performance when doing this in some cases and haven't seen > any proof of increased performance..so I'm unconvinced. I have to agree with you. The locality of reference in both these cases is not the same locality. The passing similarity caused by the file as swap store model is just that, a passing similarity. I need to take a more in depth look at the code in action; there is some unused ICE hardware around here that I might be able to leach for a bit (486, not Pentium). I suspect that varying LRU list insertion order to give persistance preference to backing store pages would help (but be a royal bitch to implement). I'd like to see the people seeing the thrashing problems add about 16M of swap without doing any extra apllications and see what happens. If the vnode pager is happy, this should be doable with a swap on file. My immediate suspicion is that the problems would just go away until the cache was filled again (this time consuming all of swap). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.