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.