Date: Thu, 30 Oct 1997 05:20:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: njs3@doc.ic.ac.uk (Niall Smart) Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org Subject: Re: help with fstat? Message-ID: <199710300520.WAA00554@usr05.primenet.com> In-Reply-To: <E0xQf52-0006j9-00@oak67.doc.ic.ac.uk> from "Niall Smart" at Oct 29, 97 08:51:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? That's what pisses me off about MADV_SEQUENTIAL... it snipes pages with possible locality to replace them with pages with no possible locality. 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. Terry Lambert terry@lambert.org --- 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?199710300520.WAA00554>