In article <[EMAIL PROTECTED]>,
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:
<snip>
>they were also claiming that they were doing a least recently used
>replacement stragegy. however, their performance group did some simple
>modeling and found that if they choose non-changed least recently used
>pages ... before choosing changed least recently used pages ... that
>the service time to handle the replacement was drastically reduced. a
>non-changed page already had an exact duplicate out on disk ... and
>therefor replacement processing could simply discard the copy in
>virtual memory and make the real memory location available.
Right. All you had to was zero the word, or half word, or bit,
that pointed at the index of the page table.
But, now you have the decision of when does the data within
that page get zeroed when it is placed into the next
address space usage list. I don't think it matters as
long as they're all done on the same side of usage.
>a
>"changed" page selected for replacement, first had to be written to
>disk before the real memory location was available. first attempting
>to select non-changed pages for replacement significantly reduced the
>service time and processing. I argued that such approach basically
>perturbed and violated any claim as to approximating least recently
>used replacement strategy. they did it any way.
>
>so os/vs2 svs eventually morphed into os/vs2 mvs ... and then they
>shortened the name to just calling it mvs. customers had been using it
>for some number of years ... it was coming up in 1980 ... and somebody
>discovered that high-useage, shared executable images (i.e. same
>executable image appearing in lots of different virtual address spaces
>and being executed by lots of different applications) were being
>selected for replacement before low-useage application data pages. The
>high-useage, shared executable images were "read-only" ... aka they
>were never modified and/or changed. The low-useage application data
>areas were constantly being changed. As a result, the high-useage
>(execution, shared) pages were being selected for replacement before
>low-useage application data pages.
They didn't keep a count of how many were sharing the code? This
means that user data pages had the same priority as code? One
would assume that all user data pages would have be written out.
>
>in much the same way that the vm370 page list management was
>constantly and significantly changing the order that pages were
>examined for replacement ... invalidating basic premise of least
>recently used replacement stragegies ... the os/vs2 (svs and mvs) was
>also creating an ordering different than based on purely use ... also
>invalidating basic premise of least recently used replacement
>strategies.
Was there a difference between exec pages and user pages?
Then a subset of those categories would have to be code
and data, with the rare exception where code is data
(writable code segment which god never meant happen).
I suppose there would also have to be special handling
of data pages that were suddenly changed to code.
Comments on the discussion:
1. An OS did not need VM to do relocation. Example: KA10.
2. Do not confuse paging hardware with virtual memory.
They are different. The reason this confusion happens
is because both were usually done during the same
major version OS release. If your new CPU has paging
hardware, you might as well schedule your VM project
at the same time. You might as well subject the customer
to both pains all at the same time. It was like
pulling a tooth: yank it and get it over with or tweak
it and have years of long drawn annoying pain in the
nethers.
/BAH
