From owner-freebsd-hackers Wed Oct 29 12:04:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA09643 for hackers-outgoing; Wed, 29 Oct 1997 12:04:28 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA09621; Wed, 29 Oct 1997 12:04:17 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id NAA21767; Wed, 29 Oct 1997 13:04:13 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd021758; Wed Oct 29 13:04:11 1997 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id NAA17154; Wed, 29 Oct 1997 13:04:04 -0700 (MST) From: Terry Lambert Message-Id: <199710292004.NAA17154@usr07.primenet.com> Subject: Re: help with fstat? To: toor@dyson.iquest.net (John S. Dyson) Date: Wed, 29 Oct 1997 20:04:04 +0000 (GMT) Cc: tlambert@primenet.com, toor@dyson.iquest.net, dyson@FreeBSD.ORG, angio@angio.net, perlsta@cs.sunyit.edu, hackers@FreeBSD.ORG In-Reply-To: <199710282204.RAA17354@dyson.iquest.net> from "John S. Dyson" at Oct 28, 97 05:04:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > It doesn't 'discard', but should either deactivate or cache the page. > > > > > > Pages are usually pretty darned unused by the time they are on the > > > inactive or cache queues. > > > > Ie: what effect does MADV_SEQUENTIAL have on cache thrashing? > > It improves it. The system works better. Ugh. We aren't communicating. If I have a clean page on the LRU already, will the MADV_SEQUENTIAL prevent a byte-based traversal of an mmap()'ed file larger than memory+swap from discarding my page? My desired behaviour is to that the system not force out my clean page in favor of the more recently used, but never again to be referenced, pages of an MADV_SEQUENTIAL file. I want the system to *not* preferentially save newer pages than mine, if the newer pages came from an MADV_SEQUENTIAL marked region, and my page did not. I'd consider normal use of the LRU by pages from an MADV_SEQUENTIAL marked region to be "cache thrashing", by definition. I'd like it to *reuse* pages in that region before going to the LRU and endangering the "in core" state of my page. Ideally, there would never be more than two pages in a MADV_SEQUENTIAL marked region in real memory or swap at any one time: The page that was previously accessed, and the page that was just accessed. Really, I want per object working set quotas, and I want MADV_SEQUENTIAL to set the quota on the backing object to two pages, but that's more of an implementation detail. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.