From owner-freebsd-hackers Tue Feb 20 21:50:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA09089 for hackers-outgoing; Tue, 20 Feb 1996 21:50:27 -0800 (PST) Received: from baygull.rtd.com (baygull.rtd.com [198.102.68.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA09078 for ; Tue, 20 Feb 1996 21:50:22 -0800 (PST) Received: (from news@localhost) by baygull.rtd.com (8.6.9/8.6.9.1) id WAA15071; Tue, 20 Feb 1996 22:50:09 -0700 To: hackers@freebsd.org Path: freefall.freebsd.org!owner-freebsd-hackers From: tinguely@plains.nodak.edu (Mark Tinguely) Newsgroups: rtd.freebsd.hackers Subject: Re: Paging questions Date: Tue, 20 Feb 1996 18:19:03 -0600 (CST) Lines: 23 Message-ID: <199602210019.SAA26552@plains.nodak.edu> NNTP-Posting-Host: seagull.rtd.com 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.