Intro(3dshm)

Synopsis

   #include <dshm.h>

Description

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

• To access a buffer, the application must have a mapping to it.

• Mapping by one process is not sufficient to allow access by another process. Each process must map its own buffers. There is one exception: in special circumstances, a process can invoke dshm_updatetlb(3dshm) to use another process's preexisting mappings. See the information about application-based threads below.

• The logical address range for a DSHM map must be the same for each address space attached to the segment.

• The shared buffer pointers for an application must exist at the same (statically mapped) logical address space attached to the segment.

• The logical address range for a DSHM map must be an exact multiple of 4 MB.

• The buffers making up a DSHM object must all be the same size.

• The buffer size must be a power of 2.

• The minimum map slot size is one page.

• No multi-LWP processes can use DSHM.

• Application-based threads multiplexed onto single-LWP processes can use DSHM if they follow these rules:

  1. All processes which can schedule the threads must attach to the DSHM segment(s).

  2. Threads cannot be rescheduled between processes while executing DSHM functions.

  3. If a thread is rescheduled to another process while it has outstanding mappings, the TLB used by the new process must first be updated for those mappings. To update the TLB, you can replicate the mappings within the new process, or use dshm_updatetlb(3dshm) to invalidate all TLB entries for the segment(s) within the new process. Each map operation must eventually be balanced by an unmap operation. One process can perform the unmap operation that balances the map operation of another process.

• Each DSHM object is locked in main memory, so creating a DSHM segment requires P_LOCK privilege.

• The aggregate number of buffers actively mapped by the application (that is, the number of buffers having a non-zero slot reference count) for a segment must never exceed the number of map slots in the map.

References

Standards compliance