From owner-freebsd-hackers Thu Feb 22 05:13:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA17737 for hackers-outgoing; Thu, 22 Feb 1996 05:13:33 -0800 (PST) Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA17717 for ; Thu, 22 Feb 1996 05:13:27 -0800 (PST) Received: from spase by sun4nl.NL.net via EUnet id AA21140 (5.65b/CWI-3.3); Thu, 22 Feb 1996 14:13:25 +0100 Received: (from root@localhost) by mercurius.spase.nl (8.6.11/8.6.11) id NAA11940 for mercurius!freebsd.org!hackers; Thu, 22 Feb 1996 13:49:08 +0100 Date: Thu, 22 Feb 1996 13:49:08 +0100 From: root Message-Id: <199602221249.NAA11940@mercurius.spase.nl> To: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >From owner-freebsd-hackers Wed Feb 21 09:42:01 1996 remote from spase Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id JAA23072 for spase.nl!dutchman; Wed, 21 Feb 1996 09:29:23 +0100 Received: from spase by sun4nl.NL.net via EUnet id AA16536 (5.65b/CWI-3.3); Wed, 21 Feb 1996 09:17:20 +0100 Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id JAA22207 for spase.nl!dutchman; Wed, 21 Feb 1996 09:00:21 +0100 Received: from spase by sun4nl.NL.net via EUnet id AA13259 (5.65b/CWI-3.3); Wed, 21 Feb 1996 08:47:46 +0100 Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id IAA21197 for spase.nl!dutchman; Wed, 21 Feb 1996 08:29:54 +0100 Received: from spase by sun4nl.NL.net via EUnet id AA10165 (5.65b/CWI-3.3); Wed, 21 Feb 1996 08:19:00 +0100 Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id HAA20259 for spase.nl!dutchman; Wed, 21 Feb 1996 07:59:50 +0100 Received: from freefall.freebsd.org by sun4nl.NL.net via EUnet id AA07255 (5.65b/CWI-3.3); Wed, 21 Feb 1996 07:46:55 +0100 Received: from sun4nl.UUCP (uucp@localhost) by mercurius.spase.nl (8.6.11/8.6.11) with UUCP id HAA19567 for spase.nl!dutchman; Wed, 21 Feb 1996 07:37:57 +0100 Received: from ra.dkuug.dk by sun4nl.NL.net with SMTP id AA06085 (5.65b/CWI-3.3); Wed, 21 Feb 1996 07:27:25 +0100 Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [192.216.222.4]) by ra.dkuug.dk (8.6.12/8.6.12) with ESMTP id GAA03365; Wed, 21 Feb 1996 06:56:52 +0100 Received: from localhost (daemon@localhost) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA18021 Tue, 20 Feb 1996 16:19:26 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA18005 for hackers-outgoing; Tue, 20 Feb 1996 16:19:22 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA17999 for ; Tue, 20 Feb 1996 16:19:16 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.1/8.7.1) id SAA26552; Tue, 20 Feb 1996 18:19:03 -0600 (CST) Date: Tue, 20 Feb 1996 18:19:03 -0600 (CST) From: Mark Tinguely Message-Id: <199602210019.SAA26552@plains.nodak.edu> To: mercurius!freebsd.org!hackers, mercurius!labinfo.iet.unipi.it!luigi Subject: Re: Paging questions Sender: mercurius!freebsd.org!owner-hackers Precedence: bulk > 1) > Assume a page is swapped to disk, then copied back in core, > and not modified afterwards. Do we keep a reference to the disk > block for the page, so as to save subsequent pageouts ? Do we > have an idea on how frequently this occurs ? I have no data on this. Before the VM code grabbed pages around the faulted page (back in 386bsd, early FreeBSD 1.0.x days) I did count the number of pages that were stored in swap, read and restored. It was VERY RARE that the page was not modified again before being placed back into storage. I checked this because I changed the code so that the VM free the page from swap when read back into memory and this went a long way to fix the swap depletion problem we had then. But I have not counted with the new VM code. if I remember correctly, it has been a long time since I was looking in that code, a larger number of adjacent pages are brought back in when a page is faulted and some of those pages may or may not be kept in memory after the transfer. I argued last time this talk came up (within a year) that in swap depletion, *one* (not the only) strategy would be to again remove the pages from swap when that page is faulted back in. but there is performance concerns and hardware is cheap counter arguement was raised and I never went back down that exploritory road. --mark.