ChorusOS man pages section 5FEA: ChorusOS Features and APIs

MEM_FLAT(5FEA)

NAME

MEM, MEM_FLAT, MEM_PROTECTED, MEM_VIRTUAL, VIRTUAL_ADDRESS_SPACE, ON_DEMAND_PAGING- memory management features

MODULE SUMMARY

There are three distinct memory management modules, providing different levels of functionality. Note that any of the modules can be used in conjunction with the persistent memory services provided by the hot restart feature (see HOT_RESTART (5fea)).

MEM_FLAT: Flat memory module

The kernel and all applications run in one unique unprotected address space. This module provides simple memory allocation services.

MEM_PROTECTED: Protected memory module

This module is targeted at real-time applications able to benefit from the flexibility and protection offered by memory management units, address translation and separate address spaces. No swap or demand paging is provided. No mapper interface is provided. Accesses to programs and data stored on secondary devices must be done by application-specific file servers.

MEM_VIRTUAL: Virtual memory module

This module supports full virtual memory with swapping in and out on secondary devices. This module has been specifically designed to implement distributed UNIX; subsystems on top of the kernel.

The module exports a generic interface to implement shared memory functionalities over a network. One ``coherency'' mapper can be present on each site to implement the application specific memory sharing strategy.

In addition to kernel code, at least one mapper must be available on each site where secondary devices are managed.

No such mapper is needed when no secondary devices are used and all the memory needed is allocated from the physical memory. In this case, the MEM_PROTECTED module is preferable to the full MEM_VIRTUAL module.

Whenever needed by the hardware, the memory module permits access to (with system specific protections) special memory such as video RAM or memory mapped I/O.

FEATURES

To select one of the memory management modules for your system configuration use the configurator command or the ews GUI tool.

If you set the VIRTUAL_ADDRESS_SPACE feature to false the MEM_FLAT module will be selected.

If you set the VIRTUAL_ADDRESS_SPACE feature to true and the ON_DEMAND_PAGING feature to false the MEM_PROTECTED module will be selected.

If you set the VIRTUAL_ADDRESS_SPACE and ON_DEMAND_PAGING features to true the MEM_VIRTUAL module will be selected.

The combination of VIRTUAL_ADDRESS_SPACE is false and ON_DEMAND_PAGING is true , is illegal.

only -

For some target platforms, ChorusOS does not implement all memory management modules. For example, ChorusOS for PowerPC 60x/750 based platforms does not implement the MEM_PROTECTED module whereas ChorusOS for UltraSPARC-IIi based platforms does not implement the MEM_VIRTUAL module.

BASIC CONCEPTS

In this section, the basic memory management concepts are described. Each memory management module provides semantics for a subset or variants of these concepts, presented here as a general introduction.

Address Spaces

The address space of a processor is split into two subsets: the supervisor address space and the user address space . A separate user address space is associated with each user actor. The address space of an actor is also called the memory context of the actor.

A memory management module may support several different user address spaces, and perform memory context switches when required in thread scheduling.

The supervisor address space is shared by every actor, but only accessible to threads running with the SUPERVISOR privilege level. The kernel code and data are located in the supervisor address space.

In addition, some privileged actors, the supervisor actors , also use the supervisor address space. No user address space is allocated for these supervisor actors.

Regions

The address space is divided into non overlapping regions . A region is a contiguous range of logical memory addresses, to which certain attributes are associated (such as access rights, for example).

Regions can be created and destroyed dynamically by threads. Within the limits of the protection rules, a region can be created ``at a distance'' in an actor other than the thread's home actor.

Protections

Regions may be created with a set of access rights or protections.

The virtual pages that constitute a memory region can be protected against certain types of accesses. Protection modes are machine-dependent, but most architectures provide at least read-write and read-only. Any attempt to violate the protections triggers a page fault . The application can provide its own page fault handler.

Protections can be independently set for ``subregions'' within a source region. In this case, the source region is split into several new regions. Similarly, when two contiguous regions get the same protections back, they are merged into one region. The programmer is warned that abusing this module could result in consuming too much of the kernel resources associated with regions.

MEM_FLAT

This module is suited for systems which do not have a memory management unit, or when use of the memory management unit is required for efficiency only.

Virtual addresses match physical addresses directly. Applications may not allocate more memory than physically available.

Address Spaces

A unique supervisor address space, matching the physical address space, is featured. Any actor can access any part of the physically mapped memory, such as the ROM, the memory mapped I/O, and anywhere in the RAM.

Regions

The context of an actor is a collection of non overlapping regions. The kernel associates a linear buffer of physical memory to each region, consisting of a memory object . The memory object and the region have the same address and size.

On a given site, memory objects can be shared by several actors. Sharing of fractions of one memory object is not available.

At region creation time, the memory object is either allocated from free physical RAM memory, or shared from the memory object of another region.

The concept of ``sharing of memory objects'' is provided to control the freeing of physical memory. The memory object associated with a region is returned to the pool of free memory when the associated region is removed from its last context. This concept of sharing does not prevent an actor from accessing any part of the physically mapped memory.

It is not possible to wait for memory at region creation time. The memory object must be immediately obtainable, either by sharing or by allocating free physical memory.

Protections

There is no default protection mechanism available.

MEM_PROTECTED

The Protected Memory module (MEM_PROTECTED) is suited to systems where memory management units are available, and where the application programs are able to benefit from the flexibility and protection offered by separate address spaces. Unlike the full virtual memory management module (MEM_VIRTUAL), it is not directly possible to use secondary storage to emulate more memory than physically available. This module is primarily targeted at critical real-time applications, where memory protection is mandatory, and where low priority access to secondary storage is kept very simple.

No external segments are defined, no mapper is used and no swap to external device is available.

Regions

The kernel associates a set of physical pages with each region, consisting of a memory object .

At region creation time, the memory object is either allocated from free physical memory, or shared from the memory object of another region.

Sharing has a semantic of ``physical sharing''.

At region creation time, it is possible to initialize a region from another region. This initialization has a semantic of physical allocation and copy at region creation time. In order to keep the MEM_PROTECTED module small, no deferred on demand paging technique is used.

A region of an actor maps a memory object at a given virtual address with associated access rights.

The size of a memory object is equal to the size of the associated region(s).

It is not possible to wait for memory at region creation time, the memory object must be obtainable immediately, either by sharing or by allocating free physical memory.

Protections

Violations of memory protection trigger memory fault exceptions that can be handled at the application level by supervisor actors.

For typical real-time applications, memory faults denote a catastrophic software failure that should be properly logged for off~line analysis. It should also trigger an application-designed fault recovery procedure.

MEM_VIRTUAL

This module is suitable for systems with page-based memory management units, and where the application programs need a high-level virtual memory management system.

The main functionalities are:

This module supports multiple protected address spaces.
On systems with secondary storage (the usual case), it is possible to allow applications to use much more virtual memory than the memory physically available.
Pages are automatically swapped in and out when appropriate.
This implementation also supports the mapping of segments into the address spaces. In the distributed case, a set of functionalities is optionally available, which allows a distributed shared memory system to be built. In this type of system, several ``readers'' and ``writers'' over the network can access the same data in a controlled manner: a coherency mapper is needed in order to do this..

Segments

The unit of representation of information in the system is the segment.

Segments are usually located in secondary storage. The segment can be persistent (for example, files), or temporary with a lifetime tied to that of an actor or a thread, for example, swap objects.

The segments are managed by independent system servers, called mappers . There can be several independent mappers coexisting in the system at a given time.

The mode of representation of the objects, the identification of the objects and the access rules (protection and sharing, for instance) are defined by these mappers. The kernel defines a uniform interface to the mappers.

The kernel itself implements special forms of segment: the memory objects that are allocated along with the regions. Optionally, the kernel can request the default mapper to create temporary external objects in order to swap these objects.

Designation of segments

Like actors, segments are designated by capabilities.

Regions

A region of an actor maps a portion of a segment at a given virtual address with associated access rights.

The memory management provides the mapping between regions within an actor and segments (for example, files, swap objects, and shared memory).

The segments and the regions can be created and destroyed dynamically by threads. Within the limits of the protection rules, a region can be created ``at a distance'': in an actor other than the requesting actor.

Many regions can define overlapping (or not) portions of segments. The segment can be shared by different actors. Segments can then be shared across the network.

The kernel also implements optimized region copying ( copy on write ).

Protections

Regions may be created with a set of access rights or protections .

The virtual pages that constitute a memory region can be protected against certain types of access.

An attempt to violate the protections triggers a page fault. The application can provide its own page fault handler.

Protections can be independently set for ``subregions'' within a source region. In this case, the source region is split into several new regions. Similarly, when two contiguous regions get the same protections back, they are combined into one region. The programmer is warned that abusing this module could result in consuming too much of the kernel resources associated with regions.

Segment representation: local caches

For each mapped segment on its site, the kernel encapsulates the physical memory holding portions of the object data in a local cache .

Local caches are the memory objects for this module.

Page faults generated during access to portions of a segment which are not accessible are handled by the kernel. In order to resolve these exceptions, the kernel may invoke the object's mapper and fill the local cache with the data received from that mapper. No access to the mapper is required when the physical page is already present in the local cache. Typically, this occurs when another actor has already mapped the page on the same site.

The consistency of an object shared among regions belonging to several actors at the same site is guaranteed by the uniqueness of the segment local cache in physical memory.

When an object is shared among actors of different sites, there is one local cache per site, the coherency mappers maintain the consistency of these distributed caches.

Explicit access to a segment

The memory management also allows explicit access to (that is, copy of) segments without mapping them into an address space.

This kind of access to a segment uses the same local cache mechanism as described above.

Object consistency is thus guaranteed during concurrent accesses on a given site, whether they are explicit or mapped. Note that mappers do not distinguish between these two kinds of access modes.

The same cache management mechanism is used for segments representing program text and data, mapped files and files accessed by conventional read/write instructions.

Explicit access to a local cache

When complex operations are applied to segments (such as distributed cache consistency or segment truncation), explicit access to the local cache data is necessary.

For this purpose, the MEM_VIRTUAL module provides facilities for controlling the state and contents of local caches.

API

The memory management API is summarized in the following table:

Function             Comment                                      FLAT  PROT. VIRT.


rgnAllocate          Allocate a region                                 +  +  +
rgnDup               Duplicate an address space                              +
rgnFree              Free a region                                     +  +  +
rgnInit              Allocate a region initialized from a segment            +
rgnInitFromActor     Allocate a region initialized from another region    +  +
rgnMap               Create a region and map it to a segment                +
rgnMapFromActor      Allocate a region mapping another region          +  +  +
rgnSetInherit        Set inheritance options for a region                    +
rgnSetPaging         Set paging options for a region                         +
rgnSetProtect        Set protection options for a region               +  +  +
rgnStat              Get statistics of a region                        +  +  +
svCopyIn             Byte copy from user address space                 +  +  +
svCopyInString       String copy to user address space                 +  +  +
svCopyOut            Byte to user address space                        +  +  +
svPagesAllocate      Supervisor address space page allocator           +  +  +
svPagesFree          Free memory allocated by svPagesAllocate          +  +  +
svPhysAlloc          Physical memory page allocator                    +  +  +
svPhysFree           Free memory allocated by svPhysAlloc              +  +  +
svPhysMap            Map a physical address to the supervisor space    +  +  +
svPhysUnMap          Destroy a mapping created by svPhysMap            +  +  +
svMemMap             Map a physical address to the supervisor space    +  +  +
svMemUnMap           Destroy a mapping created by svMemUnMap           +  +  +
vmCopy               Copy data between address spaces                  +  +  +
vmFree               Free physical memory                                    +
vmLock               Lock virtual memory in physical memory                  +
vmMapToPhys          Map a physical address to a virtual one              +  +
vmPageSize           Get the page or block size                        +  +  +
vmPhysAddr           Get a physical address for a virtual one          +  +  +
vmSetPar             Set the memory management parameters                    +
vmUnLock             Unlock virtual memory from physical memory              +

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Interface Stability	Evolving

ChorusOS 4.0 Last Revised December 1999