Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Feb 1996 13:47:33 +0100
From:      root <root@spase.nl>
To:        hackers@freebsd.org
Message-ID:  <199602221247.NAA11464@mercurius.spase.nl>

next in thread | raw e-mail | index | archive | help
>From spase!owner-freebsd-hackers  Wed Feb 21 12:47:16 1996 remote from sun4nl
Received: from spase by sun4nl.NL.net via EUnet
	id AA15376 (5.65b/CWI-3.3); Wed, 21 Feb 1996 12:47:16 +0100
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 <hackers@freebsd.org>; 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 <tinguely@plains.nodak.edu>
Message-Id: <199602210019.SAA26552@plains.nodak.edu>
To: hackers@freebsd.org, luigi@labinfo.iet.unipi.it
Subject: Re: Paging questions
Sender: owner-hackers@freebsd.org
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602221247.NAA11464>