Overwriting paging files

[Chris Torek]

In article <4135 at umcp-cs.UUCP> I wrote:
>>... It would be better if the pages were brought over and stored
>>locally until the process is done with them.  This could be done
>>as a `background task', to keep it from affecting performance much.

In article <8830 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>When would the pages be brought over?  When the program was first executed?

Yes.

>This may narrow the window of vulnerability, but it wouldn't close it
>entirely.

True---but note that most of the statistics gathered by 4BSD process
migration studies show that programs are grouped into `short lived'
and `long lived', and that there are very few `medium life' programs.
If the window is trimmed down to (say) five seconds, that would
help programs like editors considerably.  (Imagine having your
editor die after working on a file for several hours!  Fortunately,
most editors can recover from crashes, including being killed by
the kernel because the server's copy of the editor chaned).

>I also wouldn't go so far as to say doing it as a background task
>wouldn't affect performance much, without seeing some hard data ....

A point.  But on the Sun-9, this will all be done by the network
processor and the disk-I/O-processor over private memory channels
on your ten terabit LAN anyway, right :-)?

>When the file is written?

No.  Aside from the server's having to track all client paging
behaviour, by then it is probably too late anyway.  Delaying the
write while clients squirreled away their own copies might work,
but might be slow; writing a new copy would cost disk space and
kernel complexity.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu