Date: Mon, 6 Mar 95 14:57:36 MST From: terry@cs.weber.edu (Terry Lambert) To: davidg@Root.COM Cc: current@FreeBSD.org Subject: Re: more ETXTBSY bugs Message-ID: <9503062157.AA19959@cs.weber.edu> In-Reply-To: <199503061853.KAA02254@corbin.Root.COM> from "David Greenman" at Mar 6, 95 10:53:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503062157.AA19959>