Superpages PDF

Title Superpages
Author mehul vani
Course Operating Systms
Institution Binghamton University
Pages 3
File Size 58.5 KB
File Type PDF
Total Downloads 70
Total Views 132

Summary

Its a notes for superpages...


Description

SUPERPAGES 1.What are superpages? Why are they useful? What are the constraints on their sizes, placement, and page attributes (protection, reference, and dirty bits)? Many processors achieve wider TLB coverage by supporting large pages in the TLB. These pages are called Superpages. (for Why are they useful? See next qestion) Superpage size = power of 2 x the base page size. Constraints: • always should be contiguous (physically and virtually) • always should be aligned (physically and virtually) (always should me multiple super page size) • uniform protection attributes: protection attributes will be common for all superpages and cant be changed. •only one reference bit, one dirty bit. (2) Superpages A. What are the advantages and disadvantages of superpages? Advantages: Reducing TLB misses. TLB coverage will be increased. Disadvantades fragmentation issues. Poor use of main memory. B. How many TLB entries and page table entries are there for each superpage? Only one TLB entry per superpage • But multiple (identical) page-table entries, one per base page C. What are the restrictions on superpage size, allocation, and placement? Constraints: • always should be contiguous (physically and virtually) • always should be aligned (physically and virtually) (always should me multiple super page size) • uniform protection attributes: protection attributes will be common for all superpages and cant be changed. •only one reference bit, one dirty bit. (3) If a superpage has a size equal to 4 base pages, how many TLB entries are occupied by the superpage? How many page table entries are occupied by the same superpage? Explain why. Only one tlb entry is occupied by the super page. Each base has page table entry so there will be 4-page table entries. 4.How do superpages affect (increase/decrease/don’t change) internal and external memory fragmentation? Why? Internal fragmentation: we allocate a super page with certain number of base pages. If the application doesn’t use all the base pages, then there will be wastage of main memory. This leads to internal fragmentation.

External fragmentation: if you have super pages of mixed sizes like 4,8,16 base pages and so forth all over the physical memory then there will be certain chunks of free memory regions that are spread all over the physical memory. So, super pages increase both the internal and external fragmentation.

(5) In the paper, superpage allocations are performed in two steps: preemptible reservations and incremental promotions. Why do we need this two-step mechanism? If we already know how much to reserve, why not create the entire superpage in one shot the first time any of its base pages is accessed? It is to avoid the penalty in terms of performance overhead if the decision is wrong. If we directly create a super page, then we miss the two advantages that the both preemptive reservation and incremental promotion provides. Because of preemptive reservation and incremental promotion, we can reserve the base pages without allocating to other super pages. If the process doesn’t use those reserved pages in certain amount of time, then we can cancel the reservation and use them for creating other super pages. This will decrease the internal fragmentation. (8) Why do superpages make both internal and external fragmentation worse? When contiguous memory is plentiful, the OS succeeds in using superpages of the desired sizes, and achieves the maximum performance due to superpages. In practice, reservation-based allocation, use of different page sizes and file cache accesses have the combined effect of rapidly fragmenting available physical memory. To sustain the benefits of superpages, the OS may proactively release contiguous chunks of inactive memory from previous allocations, at the possible expense of having to perform disk I/O later. The OS may also preempt an existing, partially used reservation, given the possibility that the reservation may never become a superpage. The OS must therefore treat contiguity as a potentially contended resource, and trade off the impact of various contiguity restoration techniques against the benefits of using large superpages.

super Incremental promotion overhead: We synthesized an adversary application that makes the system pay all the costs of incremental promotion without gaining any benefit. It allocates memory, accesses one byte in each page, and deallocates the memory, which renders the TLB useless since every translation is used only once. This adversary shows a slowdown of 8.9% with our implementation, but as much as 7.2% of this overhead is due to the following hardwarespecific reason. PTE replication, as described in Section 6.1, forces each page table entry to be traversed six times: once per each of the three incremental promotions, and once per each of

the three incremental demotions. The remaining 1.7% of the overhead is mainly due to maintenance of the population maps. Sequential access overhead: Accessing pages sequentially as in our adversary is actually a common behaviour, but usually every byte of each page is accessed, which dilutes the overhead. We tested the cmp utility, which compares two files by mapping them in memory, using two identical 100MB files as input, and observed a negligible performance degradation of less than 0.1%. Preemption overhead: To measure the overhead of preempting reservations, we set up a situation where there is only 4MB of memory available and contiguous, and run a process that touches memory with a 4MB stride. In this situation, there is a pattern of one reservation preemption every seven allocations. Every preemption splits a reservation into 8 smaller chunks. One remains reserved with the page that made the original reservation; another is taken for the page being allocated, and 6 are returned to the free list. We measured a performance degradation of 1.1% for this process. Overhead in practice: Finally, we measure the total overhead of our implementation in real scenarios. We use the same benchmarks of Section 6.2, perform all the contiguous memory allocation and fragmentation management as before, but factor out the benefit of superpages by simply not promoting them. We preserve the promotion overhead by writing the new superpage size into some unused portion of the page table entries. We observe performance degradations of up to 2%, with an average of about 1%. This shows how our system only imposes negligible overhead in practice, so the pathological situations described above are rarely observed....


Similar Free PDFs
Superpages
  • 3 Pages