Date: Thu, 30 Oct 1997 09:50:12 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: njs3@doc.ic.ac.uk, tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: help with fstat? Message-ID: <199710301450.JAA21339@dyson.iquest.net> In-Reply-To: <199710300520.WAA00554@usr05.primenet.com> from Terry Lambert at "Oct 30, 97 05:20:47 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said: > > Does FreeBSD maintain a "free page" list internally that it will > > consult before trying the heuristics for replacing a page? If this > > is so then when we page in a page for a memory mapped region with the > > MADV_SEQUENTIAL attribute we can immediately add the previous page to the > > "free page" list. > > John does this in the OBJ_SEQUENTIAL case in vm_fault() in vm_fault.c. > > But he merely goes through the pages in the region before the faulted > region (taking read-ahead into account), and if dirty, protects and > deactivates the page, or if clean, caches it. > > My problem is with it being cached, since it's now on the LRU list > ahead of my page that's been cached, and the user promised us that > he's never going to reference the thing again. So why is it cached > instead of "cached with extreme prejudice"... ie: inserted at the LRU > head as if it were truly the least recently used instead of in LRU > order, where it can force my pages (which I *am* going to reference > again) out of core? > Firstly, if you happen to use the inferior (or pages marked MADV_SEQUENTIAL) cached pages before they are pushed off of the cache queue, they will be placed immediately on the active queue. Secondly, there are often times that one makes multiple sequential accesses of the same file. MADV_SEQUENTIAL provides a way of bypassing the pagedaemon's Least-often-used policy allowing the system to provide immediately provide the policy (in most cases) without the pagedaemon mucking things up. > > That's what pisses me off about MADV_SEQUENTIAL... it snipes pages > with possible locality to replace them with pages with no possible > locality. > By the time that pages are on the cache queue, they are statistically much less significant than if they were on the active or inactive queues. > > I think vm_page_cache() and vm_page_deactivate() need a parameter > like "defeat_normal_LRU_insertion_order" to stuff them at the other > end of the LRU so they'll be the first against the wall when someone > needs another page. > That is an interesting idea (I had thought of that), but the gain might not be as high as the cost. MADV_SEQUENTIAL gives extreme prejudice against it's pages, while still caching (some of) them to eliminate unexpected results. (Remember the B_AGE brokenness?) I am avoiding that situation. -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710301450.JAA21339>