Upload
trinhthu
View
220
Download
6
Embed Size (px)
Citation preview
CSC 256/456 Lecture
Xiaowan Dong
Private Address Spaces
Single Address Space
Architectural Support for Single Address Space
Private Address Spaces
Single Address Space
Architectural Support for Single Address Space
Private virtual address spaces provide an illusion: ◦ A program owns the entire memory, with the
starting address at 0
◦ The memory space is as large as the virtual address space
Virtual Address Space Example (32-bit)
Image Source: http://www.slideshare.net/varunmahajan06/gnu-linux-processvirtaddrspace
Each program has a private virtual address space ◦ Providing a per-process mapping from virtual to
physical address
◦ Isolation and protection
Why private virtual address space ◦ Memory is a scarce resource
◦ Virtual addresses must be multiply allocated to support each executing program with sufficient space
Is memory still a scarce resource ◦ 64-bit address space
◦ It would last 5,000 years even consumed at a rate of 100 MB/s
◦
Can we make any changes ◦ Are there any disadvantages of private virtual
address spaces
Disadvantages of Private Virtual Address Spaces ◦ Interfering with sharing and cooperation among
processes
For example, it is difficult to share pointer-based data structures
Private Address Spaces
Single Address Space
Architectural Support for Single Address Space
Now memory is not scarce any more in 64-bit machines, we could use a single address space instead
In single address space systems, addresses are unique and context-independent [1]
◦ A virtual address has the same translation, independent of the process that issues it
Single address space simplifies sharing, compared to private virtual address spaces
Advantages of single address space ◦ Facilitating sharing and cooperation
Pointers can be passed between processes and linked data structures are globally meaningful
Avoiding explicit communication between programs
◦ Simplifying the use of virtually indexed caches
Removing the problems of synonyms and homonyms
Synonym: A physical page is mapped into two or more different virtual pages
Homonym: The same virtual address in different address spaces would be mapped to different physical addresses
Image source: http://users.ece.gatech.edu/~sudha/academic/class/ece4100-6100/Lectures/Module9-MemorySystems/virtual.memory.pdf
Image source: http://users.ece.gatech.edu/~sudha/academic/class/ece4100-6100/Lectures/Module9-MemorySystems/virtual.memory.pdf
Now there is only one single address space. How to support memory protection? ◦ Protection domains
A protection domain defines a set of objects that could be accessed and the access rights ◦ Domain = set of (object, rights) pairs
Image Source: CS256/456 lecture slides, University of Rochester
Protection domain in private virtual address space: ◦ Per-process based address space
◦ Protection is supported by mapping
Protection domain in single address space ◦ The data, code and stack that can be accessed
◦ Protection is supported by specifying the objects accessible and the corresponding access rights
Can we use the translation and protection structures in multiple address spaces to support single address space ◦ Linear page tables maintained separately for each
protection domain in multiple address spaces ◦ Problems: A sparse view of the global address space
Translation mapping for shared pages could be duplicated in the page tables for each domain
New structures? ◦ A single table of translations shared by all domains ◦ A separate protection table for each domain
Private Address Spaces
Single Address Space
Architectural Support for Single Address Space
Domain-page model ◦ Protection Lookaside Buffer (PLB)
Page-group model ◦ PA-RISC
Comparison between PLB and PA-RISC
The domain-page model specifies the access rights for each (domain, page) pair ◦ Independent of the other domains and pages
◦ Multiple entries for the pages shared across domains
If we use conventional TLB and page table entries (PTE), are there any problems regarding efficiency?
Conventional TLB and PTE ◦ For shared pages, there will be duplicate translation
information, which is inefficient.
Solution ?
Conventional TLB and PTE ◦ For shared pages, there will be duplicate translation
information
Solution ◦ Splitting translation information and protection
information into two different hardware structures
◦ Protection Lookasider Buffer (PLB)
Storing protection information
Each entry contains the access rights granted to one protection domain for one specific virtual page ◦ Per domain, per page basis
What if we use virtually indexed, virtually tagged cache ◦ We do not need virtual to physical address
translation before accessing L1 cache ◦ We could remove the TLB off the critical path as
now translation and protection information are separated
Image Source: ASPLOS , “Architecture support for single address space operating systems”,1992.
Usage of virtually-indexed, virtually-tagged cache ◦ TLB could be moved out of the critical path
Only cache miss or writeback requires TLB accesses
◦ More bits are needed for the tags compared to physically tagged cache when the physical memory is smaller than the virtual memory
PLB entry only stores protection information ◦ Fewer fields
◦ Multiple entries when pages are shared
PLB could have different granularity from TLB ◦ PLB separates translation and protection
information
Superpages could improve TLB coverage, but also increase false sharing ◦ PLB could provide protection on sub-page units to
reduce false sharing
Many segments spanning many pages have a constant protection value for the entire segment ◦ Stacks, temporary heaps and code segments ◦ A single PLB entry could map the entire segment
Page-group ◦ Logical grouping of pages
◦ Each page belongs to a single page-group
Protection Domain ◦ Defined by the set of page-groups that it can
access
PA-RISC
TLB Entry ◦ A set of access rights to that page
◦ Access Identifier (AID)
Page-group number
◦ Translation information
TLB Entry
Rights AID Translation Info
Each protection domain has a set of 4 registers to store the IDs of page groups accessible to it ◦ Page-group registers (PID)
Page group 0 is global to all domains
One page is accessible to a domain, if: ◦ The AID of the page matches one of the 4 PIDs of
the domain
◦ The AID is zero
Image source: ASPLOS , “Architecture support for single address space operating systems”,1992.
The exact access rights are determined by the combination of: ◦ Rights field in the TLB entry
◦ The current processor privilege level (PL)
◦ A write-disable bit in the PID register (D)
Disabling write from a protection domain to the entire page group, regardless of the value in Rights field
Only 4 registers to store the IDs of page-groups accessible to one domain ◦ Limited
◦ No information to help OS managing replacement
Improved version ◦ A cache for the IDs of page-groups accessible to
each domain
◦ LRU replacement
Protection and translation information are combined in a TLB ◦ Only one set of access rights per page
◦ No duplicate copies for translation information
We could also separate the protection and translation information for page-group model
Attaching and detaching segments
Paging operations
Domain switches
Virtual segment ◦ Logical groupings of pages in single address space
operating system OPAL [2]
◦ A sequence of contiguous virtual pages, occupying a fixed contiguous range of virtual addresses
◦ Basic unit of sharing
Attaching segments to a domain ◦ PA-RISC
adding the page-group ID of the segments to the set of page-group IDs accessible to the current domain
◦ PLB
OS marks the segment as accessible by the domain
The individual PLB entries for each (domain, page) pair are lazily faulted into the PLB when the pages are accessed
Detaching segments from a domain ◦ PA-RISC
Removing the page-group ID from the set of page-group IDs accessible to the domain
◦ PLB
OS must invalidate the PLB entries that map the detaching segment to the current domain
Pages must be protected from access while page-in and page-out operations are in progress ◦ Exclusive access for the domains taking paging
operations
PLB ◦ System access rights are updated in the PLB entries ◦ The number of entries changed depends on the
number of domains that have access to this page
PA-RISC ◦ Pages are moved to a special page-group ◦ Adding or updating the TLB entry for the page
The page must be unmapped in the TLB and page tables, and must be flushed from the caches
PLB ◦ No maintenance required
Eventually purged from the PLB through replacement
◦ The lack of TLB entry will generate a fault thus we do not need to concern about PLB
PA-RISC ◦ Purging the corresponding TLB entry and page table
entry
PLB ◦ Requiring changing only the PD-ID register in the
processor
◦ No need to flush the PLB
PLB entries are tagged with the domain identifier
PA-RISC ◦ Purging the PID registers / page-group cache of the
previous domain
◦ Reload explicitly or lazily the page-groups of the current domain
Conventional private virtual address spaces support one address space for each process
Single address space simplifies sharing and cooperation among processes
Architectural support for single address space ◦ PLB
◦ PA-RISC
[1] Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers. 1992. Architecture support for single address space operating systems. In Proceedings of the fifth international conference on Architectural support for programming languages and operating systems (ASPLOS V), Richard L. Wexelblat (Ed.). ACM, New York, NY, USA, 175-186.
[2] Opal http://homes.cs.washington.edu/~levy/opal/
[3] John Wilkes and Bart Sears. 1992. A comparison of protection lookaside buffers and the PA-RISC protection architecture. HP Laboratories
[4] Andrew S. Tanenbaum. 2007. Modern Operating Systems (3rd ed.). Prentice Hall Press, Upper Saddle River, NJ, USA.