The answer: If the number of page frames is exactly equal to the number of TLB entries, then we can use the same policy for page replacement as we use for TLB entry replacement, and we can permanently assign one TLB entry to each page frame. In this case, it is trivial to see that every TLB miss is also a page fault, and that the added overhead of TLB management by the page fault service routine is negligable.recognize that this cost is a function of the ratio of TLB entries to page frames in main memory, and it should comment on the expected performance penalty when this ratio is one, greater than one, and less than one.The same holds when, for some reason, the TLB has more entries than there are page frames. The extra entries, in this case, can simply be ignored by setting them to an invalid virtual address. The remaining entries can be associated with page frames, as above.
If the number of page frames is larger than the number of TLB entries, there is a problem. Some page faults in such a system will represent TLB misses when the corresponding page is already in main memory. In this case, the fault handler must maintain both a page replacement policy and a TLB entry replacement policy, and the performance will be reduced both by the extra faults and by the overhead of maintaining two replacement policies.
Some students asked why a TLB designer would include more TLB entries than there are page frames. The answer is simple. If the TLB is mass produced, there would generally only be one size available, and it is quite possible that someone who needed a small system configuration would buy fewer page frames of main memory than there are TLB entries in the standard product.
The answer: In the problem statement, it clearly stated that main memory holds a number of segments, some of which are program segments, some are stack segments, and some are heap segments. If, on context switch, the segments needed by the next process are already in memory, no swapping is needed. Assuming that the system uses something like LRU replacement of segments in main memory, it is quite likely that shared code segments will remain in main memory. If the currently active set of processes is small, if most share the same code segments, and if each process in the set has only a small stack and a small heap, it is quite possible that no swapping will be needed.
The question, part B: Explain why the early UNIX fork operation didn't need to duplica the code segment of the process being forked.
The answer: Unix code segments are usually reentrant, read only, and shared.
The question, part C: Explain the problem raised by the semantics of the UNIX fork operation in the context of virtual memory.
The answer: With swapping, a data segment (stack or heap) can be replicated using the DMA hardware of the system, in a single disk operation. One copy then ends up on disk for the child process, and another copy remains in main memory, for the parent. If virtual memory is used, each page of the segment must typically be copied using a separate disk operation, and if any pages are currently on disk, they must be brought into main memory to be copied. Thus, what could be done in a single disk transfer with swapping now takes many disk transfers, each analogous in cost to a page fault.
The answer: There are two significant changes here, and each has an effect. First, we have moved from a small memory address space to a large one, and second, we have moved from real memory to demand paged virtual memory. Both changes have effects.
The change from a small memory to a large one means that the lazy merger scheme will make less frequent sweeps through the heap to merge free blocks, but that, on the average, these sweeps will likely be longer. Furthermore, because the allocation scheme is lazy, the entire heap will be used and chopped up into little blocks before a sweep is initiated.
The move to virtual memory means that locality becomes an issue. A sweep through the heap is, by definition, not a local event! Thus, what may at other times be a well behaved application exhibiting good locality will behave badly when the lazy storage manager begins a sweep through the heap.
Finally, if the heap is significantly larger than the application needs, the use of lazy allocation almost guarantees that the objects used by the application will eventually be uniformly distributed throughout the heap instead of compacted in one part of it. This is also a locality problem!
The latter is the greatest problem with the move of a lazy heap manager to a virtual memory environment. Heap managers that use prompt merger have better locality during the merger process, since recently deallocated blocks are likely to be recently used, and, if the used fraction of the heap is small, they can easily be designed to have a higher probability of reusing old space, thus improving locality when compared with a manager that eagerly marches off into previously unused parts of the heap instead of reusing old areas.