🚀 go-pugleaf

>>3) The real reason for virtual memory (and the one which won't
>>away when memories get big) is that I can quickly load [a]
>>working set of a large program ...

>... but it seems to me that you'll use up [the faster startup] and
>a lot more in page faults.  Since you are reading the program
>piecemeal into virtual memory you are going to be a lot slower
>because of the extra seek and rotational delays. It is sort of like
>a guy driving on a surface street, instead of going over and getting
>on the freeway. You get started faster, but you hit all those
>traffic lights. The only case that is valid is if the overwhelming
>majority of the pages in the program are never referenced.

another analogy (and one that i've been using) is this:  imagine
that you have to xerox ten sets of notes and each set consists of
ten pages.  if there is a large setup time on the machine, you would
like to copy the 100 pages in one shot.  even without a large setup
time, if there are other people on line, you would probably want to
copy all of your work in one shot instead of getting on the end of
the line every 10 pages.

the answer is "it depends".  if your executable is on a unix file
system, you probably would have to do multiple i/os to load the
entire address space anyway.  however, if it is contiguous on some
swap device, then it depends on program behavior.

one important aspect that people rarely consider when talking about
response time and loading is what happens if, in the process of demand
paging (and loading of "working sets"), memory runs out?  what are
the implications on response time then?  it would seem that without
any other aids, pure demand paging is a clear loser in this situation.

danny chen
ihnp4!hou2b!dwc