Intro -- introduction to Dynamically Mapped Shared Memory (DSHM)


   #include <dshm.h>


The Dynamically Mapped Shared Memory (DSHM) facility allows single-instance databases to use very large (multi-GigaByte) main memory on ix86(TM) family systems.

Some Pentium ® processors (Pentium Pro and up) support a 36-bit physical address space, up to 64 GB of main memory. However, the ix86 instruction set is limited to 32-bit logical addresses. Most database implementations assume that all of main memory can be accessed directly within the user address space, and that processes within each instance of a database share a buffer pool. Without software changes, the buffer pool cannot exceed 4 GB. On a system with a large number of processors, database workloads would thrash in this size buffer pool.

DSHM enables a single-instance database to overcome the ix86 logical addressing barrier. Instead of statically mapping the entire shared buffer pool into its user address space, database processes share a set of dynamically managed mappings (map slots) from the user address space onto the buffer cache. The DSHM object is the buffer cache; that is, it is divided into a number of fixed-size buffers. In order to access a buffer, the application must first request that the system establish a mapping to it. The system chooses an available map slot, establishes the mapping, and returns the address of the slot where the buffer can be accessed. The pointer used to return the buffer address is shared with all users of the object. Due to the limited number of map slots, the application must unmap the buffer when it is finished with it.

At the kernel interface, DSHM extends the UnixWare shared memory model. The database buffer pool resides in a shared memory object limited in size only by available main memory--each DSHM object is locked in main memory. All processes sharing a DSHM object attach it to the same range of logical addresses. This address range is the DSHM map, a region of shared address space. The map is divided into a number of fixed-size slots. A user-level library manages the assignment of individual map slots to buffers within the DSHM object. The library caches map slot assignments to minimize the overhead associated with dynamic mapping. Any change to a map slot is visible to all processes that have attached the map. Although the kernel implements this shared address space region, performance considerations require that the user library manage the coherency of hardware Translation Lookaside Buffers (TLBs) for access to recently changed map slots.

Application constraints

DSHM places the following constraints on the application:


dshm_alignment(DSHM), dshm_attach(DSHM), dshm_bufindex(DSHM), dshm_control(DSHM), dshm_detach(DSHM), dshm_get(DSHM), dshm_map(DSHM), dshm_minmapsize(DSHM), dshm_reattach(DSHM), dshm_unmap(DSHM), dshm_updatetlb(DSHM)

Standards compliance

These routines do not conform to any current industry standard.
© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 - 01 June 2005