Define the utilization of a resource (over some period of time) to be the percentage of time that the resource is being used. When you measure the utilizations of different resources in the system, you find that the utilization of the CPU is 20%, the utilization of the backing store disk is at 99%, and the utilizations of the other devices (such as the other disks and the network adaptor) are 5% or lower.
The system is thrashing: a majority of the
time is being spent waiting for pages to be transfered between backing
store and main memory.
0 100 200 300 400 500 0 100 200 300 400 500 ...
Let there be 400 bytes of physical memory.
If the page size is 100 bytes, then there are four page frames and the page reference string is 0 1 2 3 4 5 0 1 2 3 4 5 ... Each page reference will result in a page fault: starting with the fifth reference, a reference to page i forces page (i + 4) mod 6 to be discarded. In particular, for any positive integer k after 6k references there will be 6k page faults.
If we double the page size to 200 bytes, then there are two page frames, and the page reference string is 0 0 1 1 2 2 0 0 1 1 2 2 ... There are stuttered references in this string, and each stuttered sequence results in only one page fault. Hence, for any positive integer k after 6k references there will be 3k page faults: the page fault rate is halved.
If we halve the page size to 50 bytes, then there
are eight page frames, and the page reference string is 0 2 4 6 8 10 0
2 4 6 8 10 ... There are only five distinct pages in this string, and so
there will be only five page faults for any prefix of this string whose
length is at least five.
The limit on this value comes from the requirement
that a page table consume no more than one page. Since a page table entry
consumes one word (there's a lot of wasted bits here!), a page table can
cover up to 512 pages. Hence, |p| is also 9.
Substituting, we have either |s1|
= 9 and |s2| = n - 18 or |s1|
= n - 18 and |s2| = 9. Thus, n must be
at least 19. If n = 27 then the question is trivial: both fields
have length 9, and so neither is preferable. If n != 18 then the
question reduces to is it better to have |s1|
larger than |s2| or not? and we instantiate
the choice of rules above depending on the answer to this question and
whether n is at least 20 or not.
In either case, there will be one segment table with a maximum size of 2|s1|words and 2|s1| second level segment tables, each of a maximum size of 2|s2| words. Hence, the maximum space that can be consumed by segment tables is 2|s1| + 2|s1| + |s2|. With no other information to go on, choosing a smaller |s1| results in less physical memory being devoted to segment tables.
One can imagine, however, a management scheme in which one had more first level segments, each devoted to a process. If a process never requires more than 2|s2|+|p|+|w| words of virtual memory, this scheme simplifies page and segment table management.
Would either choice result in a larger virtual address space? Explain.
Neither choice, of course, will result in a larger virtual address space: in either case, there are 2n addressable words.
Are these two arguments correct? Which policy, if either, should be preferred? Why?
Both arguments are correct to a point, and neither
should be preferred because each doesn't address the issue of thrashing.
The degree of multiprogramming should be adjusted to ensure that each process
can obtain its working set of page frames.