TMP_CTL(2SEQ) DYNIX/ptx TMP_CTL(2SEQ) NAME tmp_ctl - multi-processor control SYNOPSIS #include int tmp_ctl(command, arg) int command, arg; DESCRIPTION tmp_ctl allows processes to query the status of the processor pool and quad pool resources. Processes with the appropriate permissions can also change the configuration. The defined commands (from tmp_ctl.h) have the following meanings: TMP_NENG returns the number of processors configured in the processor pool. The processors may be online or offline. However, deconfigured processors will not be included. The arg argument is ignored. TMP_RGN_NENG returns the number of processors configured in the processor pool of the caller's region. The processors may be online or offline. However, deconfigured processors will not be included. The arg argument is ignored. TMP_OFFLINE shuts down the processor specified by arg. The processor stops dispatching processes and is paused. You must have the appropriate permissions to offline a processor. TMP_ONLINE starts up the processor specified by arg. The processor initializes and begins scheduling user processes. You must have the appropriate permissions to online a processor. TMP_QUERY returns the state (TMP_ENG_ONLINE or TMP_ENG_OFFLINE) of the processor selected by arg. TMP_TYPE returns the type (TMP_TYPE_386, TMP_TYPE_486 or TMP_TYPE_586) of the processor selected by arg. TMP_RATE returns the processor speed (in Mhz) of the processor selected by arg. TMP_NQUAD returns the number of quads configured in the quad pool. The quads may be online or offline. However, deconfigured quads will not be included. The arg argument is ignored. TMP_RGN_NQUAD returns the number of quads configured in the quad pool of the caller's region. The quads may be online or offline. However, deconfigured quads will not be included. The arg argument is ignored. TMP_ENGTOQUAD returns the quad on which the processor specified by arg. is located. TMP_QUADNEXTENG, given a processor number (specified in arg ), returns the next processor on that quad, or the first processor on that quad if there are no more processors on that quad. TMP_RGN_QUADNEXTENG, given a processor number (specified in arg ), returns the next processor on that quad in the caller's region, or the first processor on that quad if there are no more processors on that quad in the caller's region. TMP_QUADTOENG returns the first processor located on the quad specified by arg. TMP_RGN_QUADTOENG returns the first processor located on the quad specified by arg in the caller's region. DIGANOSTICS The call returns 0 on successful completion, or the desired information in the case of the query operations. The call returns -1 on error and errno is set to indicate the error. ERRORS The tmp_ctl fails if: [EBUSY] Attempting to offline a processor that has bound drivers or bound processes, or attempting to offline the last processor. [EINVAL] the processor specified by arg is already offline or online. [ENODEV] arg is bad. [ENXIO] arg is out of range. [EPERM] Process does not have the appropriate permissions and an attempt to change the processor pool configuration was made. SEE ALSO tmp_affinity(2SEQ), online(1M), priv_ctl(2SEQ) NOTES This is a Sequent library routine. To use it, specify the -lseq option to link with the Sequent library. Since this is a Sequent extension, code using this routine may not be portable to other systems. THREAD-SAFETY NOTES tmp_ctl: Thread-safe. DETACH_PROC(1M) DYNIX/ptx DETACH_PROC(1M) NAME detach_proc - detach processes from quads SYNOPSIS detach_proc DESCRIPTION The processes whose process ID numbers are listed in pid_list are detached from whatever quads they are currently attached to, making them eligible for all future automatic process migrations for load-balancing purposes. The specified processes must belong to the current user unless the current user is the superuser. EXIT STATUS detach_proc exits with status 1 if invoked with a null pid_list. Otherwise, the exit status specifies the number of processes that failed to detach from their respective quads. SEE ALSO attach_proc(1M), detach_proc(2SEQ) GETENGNO(3SEQ) DYNIX/ptx GETENGNO(3SEQ) NAME getengno, GETENGNO, getquadno, GETQUADNO, engdata_init, all_processors_support_mmx, all_processors_support_simdx - get/init user-visible engine data SYNOPSIS cc [flags] file ... -lseq [library...] #include int getengno(void), GETENGNO() int getquadno(void), GETQUADNO() int all_processors_support_mmx(void) int all_processors_support_simdx(void) void engdata_init(void) DESCRIPTION These interfaces are provided for the benefit of application processes that want to take advantage of the NUMA (Non Uniform Memory Access) architecture, or specific processor instruction set extensions (MMX and/or the Streaming SIMD extensions). These are very fast and efficient interfaces (overhead is only a very few clock ticks) to obtain certain information, such as the engine number and the quad number that a process is currently executing on, or the presence of MMX and/or Streaming SIMD extension instruction support. engdata_init establishes access to the getengno, GETENGNO(), getquadno and GETQUADNO interfaces, making the data accessible in the address space of the calling process for subsequent use. engdata_init should be called once and must precede the first call to any of these interfaces. getengno, when called from within a user process, returns the engine number on which the process is currently running. GETENGNO() is a cpp macro that eliminates the overhead of a function call and gives the same result. getquadno returns the quad number on which the process is currently running. GETQUADNO() is the equivalent cpp macro. The cpp macros GETENGNO and GETQUADNO are defined in the /usr/include/engdata.h header file. The all_processors_support_mmx() and all_processors_support_simdx() primitives are defined in the /usr/include/engdata.h header file as in-line assembly-code operations, and return a non-zero value only if all processors in the system respectively support the MMX and Streaming SIMD extension instructions. The engdata_init primitive does not need to be invoked to use the all_processors_support_mmx() or all_processors_support_simdx() primitives. NOTES The access established to the data items via engdata_init is inherited by forked processes. The GETENGNO() and GETQUADNO() macros are compiled in-line. The all_processors_support_mmx() and all_processors_support_simdx() primitives are in-lined assembly operations which execute in a maximum of seven instructions. As a special case, when the all_processors_support_mmx() primitive returns false (zero), this only means that at least one processor is present in the system which does not support the MMX instruction set. Hence, MMX instructions can still be used even if all_processors_support_mmx() returns false (zero), provided that the calling processor is found to support the MMX instruction set by use of the CPUID instruction, and the application has taken the necessary steps to ensure that it will not be run on a processor in the system that does not support the MMX instruction set (e.g., through the use of the onproc(1M) command). Without such care in a mixed processor system, the application could begin running on a processor that supported the MMX instruction set, and then conceiveably find itself context-switched to an earlier generation processor (e.g., a PentiumPro processor) which does not support the MMX instruction set. This state of affairs can only ever occur on Sequent NUMA systems with a mixed processor configuration in which first generation PentiumPro processors are present, along with later generation PentiumII, PentiumIII, etc. processors. However, These configurations are not frequently encountered. Hence the application writer is usually best served by simply consulting the return value of the all_processors_support_mmx() primitive, and then directing program flow accordingly. In the case of Streaming SIMD extension instruction support, no such caveats exist as exist for the case of MMX instruction use on mixed processor systems. The Streaming SIMD extension instructions can only be used on Sequent platforms if the all_processors_support_simdx() primitive returns boolean true (non-zero), in which case all processors in the system support the streaming SIMD extension instructions, and the operating system has enabled the use of these instructions. All of the interfaces described by this manual page are Sequent library interfaces. To use them, specify the -lseq option to link with the Sequent library. Since these are Sequent extensions, code using these routines may not be portable to other systems. THREAD-SAFETY NOTES GETENGNO, GETQUADNO, engdata_init, getengno, getquadno, all_processors_support_mmx, and all_processors_support_simdx are all Thread-safe. MMAP(2) DYNIX/ptx MMAP(2) NAME mmap, mmap64, mmapq, mmap64q - map an open file into the process's address space SYNOPSIS #include #include void *mmap (void *addr, size_t len, int prot, int flags, int fd, off_t pos) void *mmap64 (void *addr, size_t len, int prot, int flags, int fd, off64_t pos) void *mmapq (void *addr, size_t len, int prot, int flags, int fd, off_t pos, quadset_t *qsp) void *mmap64q (void *addr, size_t len, int prot, int flags, int fd, off64_t pos, quadset_t *qsp) DESCRIPTION The mmap() function establishes a mapping between a process's address space and a virtual memory object, such as a file or an anonymous shared memory region, depending on the value of the flags parameter. For a mapped file region, mmap() causes the file referenced by fd, starting at byte pos for len bytes, to be mapped into the calling process's address space. For an anonymous region, mmap() causes a zero-filled memory region of len bytes to be mapped into the calling process's address space. The process's access to the region is determined by prot, and whether the region is shared or private is determined by the flags parameter. The addr and len parameters specify the starting address and length in bytes for the new region. The address must be a multiple of the page size returned by sysconf(_SC_PAGE_SIZE), if MAP_FIXED is specified in flags (see later discussion). If len is not a multiple of the system page size, the system will round the map up to a page size boundary. The fd parameter may reference an open regular (IFREG) or character special (IFCHR) file, or may be 0 in the case of a MAP_ANONYMOUS map. For character special files, the underlying device driver must support mapping for this to succeed. Typically, a regular file is used to map shared memory. For mapped file regions, the pos parameter indicates the byte offset at which to begin mapping in the file. For anonymous regions, pos is unused. mmap() fails for regular files if an attempt is made to map a file offset beyond the offset maximum established in the open file description (see open(2)). The prot parameter specifies the mapped region's access permissions. The prot parameter should be PROT_WRITE for write access to the mapped region, PROT_READ for read access, and PROT_EXEC for executable access. These values can be ORed to obtain read-write access, etc. For programming convenience, PROT_RDWR is defined as (PROT_READ|PROT_WRITE). For file maps, the underlying file access permissions must allow the requested access specified by the prot parameter, as described below. For anonymous maps, there are no restrictions on the requested access permissions. For shared file maps (see the MAP_SHARED option specified by the flags parameter), PROT_WRITE access is granted only if the file access permissions on fd also allow write access. For private file maps (see the MAP_PRIVATE option specified by the flags parameter), PROT_WRITE access can be specified irrespective of the underlying file access permissions. In all other cases however, the file access permissions on fd must grant at least read access. By itself, this is sufficient to allow PROT_EXEC and/or PROT_READ mappings to be created. In addition, if fd refers to a regular file, the file access permissions on fd grant execute access, and PROT_EXEC is specified in prot, then the map will not be established if any other process in the system has the file open for writing. Otherwise, the mapping operation succeeds (provided that no other error conditions arise), and all subsequent attempts by any process to open the mapped file for writing will fail with an error return of ETXTBSY, until all PROT_EXEC mappings created in this manner are released. If PROT_NONE is specified, then the process has no access to the mapped region. The prot parameter affects only the calling process; other processes mapping the same file may have different access. The flags parameter specifies attributes of the mapped region. The following values may be OR'ed together to construct the map's attributes. MAP_FILE Create a mapped file region. MAP_ANONYMOUS Create an unnamed memory region. MAP_VARIABLE Allow the system to determine the address at which to place the map. MAP_FIXED Place the region at a fixed address. MAP_FIXEDSAFE Do not create the new mapping if any existing user virtual space would be replaced by the new mapping. MAP_SHARED Changes to the region are shared with other processes accessing the same region. MAP_PRIVATE Changes to the region are private. MAP_FIRSTREF Allocate the pages on the quad that makes the first reference to the page. MAP_MOSTFREE Allocate the pages on the quad with the most free memory. MAP_DISTRIBUTE Allocate the pages evenly across all quads. Of these flag values, one of MAP_PRIVATE or MAP_SHARED must be specified. One of MAP_FILE or MAP_ANONYMOUS may be specified; otherwise the default is MAP_FILE . One of MAP_VARIABLE or MAP_FIXED may be specified; otherwise the default is MAP_VARIABLE. Only one of MAP_FIRSTREF, MAP_MOSTFREE or MAP_DISTRIBUTE can be specified; otherwise the default is MAP_DISTRIBUTE. If MAP_FIXEDSAFE is specified, then MAP_FIXED must also be specified. The MAP_FILE and MAP_ANONYMOUS flags control whether the region to be mapped is a mapped file region or an anonymous shared memory region. If MAP_FILE is set, the file associated with fd is mapped. The pos parameter specifies the file byte offset at which the mapping starts, and must be a multiple of the system page size. If the len and pos field extend more than a page boundary beyond the end of the file, an error is returned. Processes should not access the region between the end of the file and the end of the final page of the region. Modifications in this region will not be written to the file, and this region may be zeroed unexpectedly. If MAP_ANONYMOUS is set, a new memory region is created and initialized to all zeros. This memory region can only be shared with descendents of the current process. For anonymous maps, the fd and pos parameters are ignored. The MAP_PRIVATE and MAP_SHARED flags control the visibility of modifications to the mapped file or anonymous region. If MAP_SHARED is set and the region is a mapped file region, modifications will be visible to other processes which have mapped the same region using MAP_SHARED , and will also be written to the file. If MAP_SHARED is set and the region is an anonymous region, the region will be shared between this process and any children who inherit the mapped region. If MAP_PRIVATE is set, modifications to the region will not be visible to other processes which have mapped the same region using either MAP_PRIVATE or MAP_SHARED. In addition, if the region is a MAP_FILE region, modifications will not be written to the file. The paging policy flags: MAP_FIRSTREF, MAP_MOSTFREE and MAP_DISTRIBUTE control which quads pages for the mapped region come from. The paging policy flags are in affect for all versions of the mmap() system call. The mmap() and mmap64() versions use a default quadset involving all quads in the system and mmapq() and mmap64q() can be used to specify a quadset with fewer than the full compliment of system quads. The MAP_VARIABLE and MAP_FIXED flags control the placement of the mapped region. If addr is non-NULL and is also a multiple of the page size returned by sysconf(_SC_PAGE_SIZE), or MAP_FIXED is set, then the region will be placed at the requested address if possible. If MAP_VARIABLE is set, and the map can't be placed at the requested address, the system selects an address for the region. If MAP_FIXED is set and the map can't be placed at the requested address, or the requested address is not page aligned, an error is returned. If addr is NULL or not page aligned, and MAP_VARIABLE is set, then the system selects an address for the region. Note that when the system selects an address, it is guaranteed not to overlap any valid address space already existing in the process. When a user-requested addr is specified, a successful mapping will replace any previous mappings for the process in the range specified by addr and len, provided that MAP_FIXEDSAFE is not also set (note: MAP_FIXEDSAFE is a non-standard extension to the mmap() system call). In any case, mmap() will not create a region that overlaps a shared memory region created by the shmat(2) system call, nor will it create a region that overlaps the process stack. A successful mmap() invocation returns the address at which the new mapping exists. If address and len specify a nonexistent part of the process's address space, then new virtual space is created as needed to accomodate the request. The process's break address (see brk(2)) is never changed by mmap(). References to any "holes" in the process's address space between the various mapped regions and/or the process stack result in a segmentation fault (SIGSEGV). When memory is mapped to a regular file, the file acts like a paging area for the mapped memory region. read and write operations to mapped regions of the file also affect the corresponding memory. The memory contents are copied out to the file when the process is swapped or when it exits, and when the region is otherwise unmapped by the last process that has it mapped. For programs that use shared memory but do not need a permanent disk image of the memory, the file associated with fd can be unlinked (see unlink(2)) even before the call to mmap(); if the file is unlinked when the region is unmapped, the disk space is not updated. A close(2) operation on the fd does not unmap the region, that is, the mapping persists. The map is implicitly deleted on exit(2) or explicitly by calling munmap(2). When a regular file is mapped with write access, any non- existent space in the file at the time of the mmap() request (for example, in a sparse file) is allocated, and filled with zeros when referenced. The type of file referenced may impose further restrictions on the pos, addr, or other parameters. Refer to the manual entry of the relevant device driver (for example, pmap(7)) for details. mmap() can be called multiple times with the same file descriptor, resulting in several (possibly overlapping) mapped regions. A process can have in excess of 3,500 maps instantiated simultaneously; mappings that are completely overlapped by subsequent mappings are not counted in this total. Mappings of regular files that use the same file descriptor, and addr and pos parameters that align virtually with a previous mapping, also don't count in this total; the simplest case of which is mapping more of a file, starting from the end of a previous mapping. All mapped files remain mapped in both the parent and child process after a fork(). All exec() and exit() system calls, when successful, remove all maps the calling process had established. There are three types of mapping: paged, physical, and non-paged memory. The type of mapping is determined by the type of file being mapped. Paged maps support shared memories and mapped regular files. Physical maps deal with hardware that has restrictive access capability (for example, the address space). Non-paged memory maps are typically used for special reserved areas of system memory; they are assumed to behave exactly like memory, supporting accesses of arbitrary size and alignment, DMA, etc. System services (raw I/O, read/write, stat, etc.) are supported in paged and non-paged memory maps; attempts at such services in physically mapped address space result in an error, typically EFAULT. Core dump files include a copy of any mapped address space; however, physically mapped address space has no corresponding image in a core file (although all physically mapped address space is recorded in the program headers of the core file, the file size field of all such program headers is zero). Regular files (IFREG) are always page-mapped. Character special files (IFCHR) can support physical, or non-paged maps, depending on the underlying hardware. Physical and non-paged maps are always valid in the process address space; references do not cause a page fault. When mmap() defines new virtual space in a program's address space, it also attempts to increase the allowable resident set size for the process accordingly. SEQUENT API EXTENSIONS mmap64() behaves the same as mmap(), except that it uses the 64-bit off64_t file offset type for pos. mmap64() is useful for mapping file offsets too large to be represented in an off_t. mmapq() behaves the same as mmap(), with the addition of the qds parameter used to restrict the set of quads the paging policy flags MAP_FIRSTREF, MAP_MOSTFREE and MAP_DISTRIBUTE affect. By default mmap() and mmap64() assumes a quadset containing all the quads in the system. The mmapq() and mmap64q() variants are used to specify a quadset with fewer quads to restrict the paging policy to just those quads in qds. See quademptyset(2SEQ) for information on construction of quadsets. mmap64q() is the union of mmap64() and mmapq() in that it allows the specification of 64-bit offsets with pos and a restricted quadset with the qds parameter. mmap64, mmapq and mmap64q are Sequent library routines. To use them, specify the -lseq option to link with the Sequent library. Since these are Sequent extensions, code using these routines may not be portable to other systems. DIAGNOSTICS Upon successful completion, mmap() returns the address at which the mapping was placed. Otherwise it returns (void *)-1 and errno is set to indicate the error. Callers of mmap() should be careful to not cast the mmap() return value to an integer, and then test the resulting value for < 0 as a means of detecting failure, as the size of user virtual space can make the address returned by mmap() appear negative when viewed as a signed integer. EXAMPLES The following code sets up a 1-Mbyte region of shared memory at the first page boundary above the current program break. This region is shared with the process's children and with any other process that maps the file shmem: pgsz = sysconf(_SC_PAGE_SIZE); shm_base = (void *)(((uint_t)sbrk(0) + (pgsz-1)) & ~(pgsz-1)); fd = open("shmem", O_CREAT | O_RDWR, 0666); shm_base = mmap(shm_base, (size_t)0x100000, PROT_RDWR, MAP_SHARED|MAP_FIXED|MAP_EXTEND, fd, (off_t)0); As a second example, the following code sets up a 64-Mbyte region of shared anonymous memory, at an address chosen by the system in the address space of the calling process. The resulting shared anonymous memory region will be shared with any of the process's children. anon_base = mmap((void *)0, (size_t)0x4000000, PROT_RDWR, MAP_SHARED|MAP_ANONYMOUS, 0, (off_t)0); ERRORS [EACCES] fd does not allow the desired access (read or write), or a write-only file descriptor was used. [EDEADLK] An attempt was made to mmap() a file that resides on a file system having a logical block size smaller than the system page size. [EFBIG] The pos and len parameters would create too large a file. [EOVERFLOW] The file is a regular file, and the value of pos + len exceeds the offset maximum established in the open file description (see open(2)). [ENXIO] The pos and len parameters specify a range that is invalid for the file associated with fd. [EINVAL] addr is not a multiple of the system page size, and MAP_FIXED is specified in flags. [EINVAL] pos is not a multiple of the system page size. [EINVAL] An invalid prot was specified; flags did not specify one of MAP_SHARED, or MAP_PRIVATE, or flags specified both of MAP_FILE and MAP_ANONYMOUS or both of MAP_FIXED and MAP_VARIABLE, or MAP_FIXEDSAFE was specified in flags without MAP_FIXED. [EINVAL] The process is the child of a vfork(2), and the process is executing a COFF-based executable. [EINVAL] The fd parameter identified a regular file which has mandatory record locking enabled. [EINVAL] For mmapq and mmap64q, more than one of MAP_FIRSTREF , MAP_MOSTFREE or MAP_DISTRIBUTE were set. [EINVAL] For mmapq and mmap64q, none of MAP_FIRSTREF , MAP_MOSTFREE or MAP_DISTRIBUTE were set. [EINVAL] For mmapq and mmap64q, the quadset in qds is either empty or not a proper subset of the quads available in the system. [EBADF] The fd parameter is not a valid file descriptor. [EFAULT] For mmapq and mmap64q, qds points outside the allocated address space of the process. [EFAULT] The address range [addr, addr + len) overlaps all or a portion of the process stack. [EFAULT] The address range [addr, addr + len) overlaps all or a portion of previously existing address space, and MAP_FIXEDSAFE and MAP_FIXED were both specified in flags. [EMFILE] The system-imposed per-process maximum limit on the number of mmap()ed files (currently in excess of 3,500), would be exceeded. [ENFILE] The system-wide limit on the number of mapped regular files was exceeded. This limit is defined by the kernel configuration variable nmfile in param_space.c. [ENODEV] The device driver indicated by fd does not support mapping. [ENOMEM] The address range [addr, addr + len) overlaps a map previously established by shmat(2). [ENOMEM] MAP_FIXED was specified in flags, and the range [ addr, addr + len) exceeds that allowed for the address space of the process, or MAP_FIXED was not specified, and there is insufficient room in the address space to establish the mapping. [EAGAIN] There is not sufficient swap space available to establish the mapping. [ENOSPC] A mapped regular file was sparse and there was insufficient space in the file-system to satisfy the request. [ESTALE] The NFS client machine has an invalid file handle for a file or filesystem on the NFS server machine. [ETXTBSY] The fd parameter specified a regular file with execute permission, the prot parameter specified PROT_EXEC, and the file to be mapped was found to be open by at least one process in the system for writing. Other error values may be returned by some device drivers when requested to map. See the relevant driver manual entry for details. SEE ALSO exec(2), fork(2), open(2), sysconf(2), munmap(2), vm_ctl(2SEQ), mmap64(2SEQ), mprotect(2), msync(2), pmap(7), zero(7), quademptyset(2SEQ) NOTES Due to a hardware restriction, PROT_WRITE implies PROT_READ, and PROT_EXEC is ignored by the hardware. THREAD-SAFETY NOTES mmap, mmap64, mmap64q, mmapq: Thread-safe. BUGS A mapped file may not be truncated. COMPATIBILITY Changes in DYNIX/ptx V2.0 In the ptx V2.0 release, mmap() was modified, primarily to conform to the AES Standard definition. The changes made to mmap() entailed interface differences as well as semantic changes. For backwards compatibility, programs compiled with pre-V2.0 system header files continue to function correctly with the old interfaces and with the old semantics. Prior to V2.0, the flags parameter supported only the following values: MAP_PRIVATE, MAP_SHARED, and MAP_ZEROFILL. MAP_PRIVATE and MAP_SHARED had the same meaning as described above. MAP_ZEROFILL was the equivalent of a MAP_PRIVATE | MAP_ANONYMOUS map. All mmap() calls were MAP_FIXED (i.e., the system never selected an address). The return value of mmap() changed in V2.0 to return the address of the mapped region on success. Previously, it returned zero for success. The only noticable semantic change was that mmap() previously extended the file if the pos and len parameters mapped beyond the end of the file and the process had write access to the file. This resulted in zero padding at the end of a non-block-aligned file. Beginning in V2.0, files are not extended. Attempts to create maps that extend more than a page boundary beyond the end of file are failed. Changes in DYNIX/ptx V4.0 In DYNIX/ptx V4.0, all prior semantics continue to be supported. However, support for a new device, /dev/zero, has been added for SVR4-based applications that allocate anonymous memory via this mechanism. The restriction preventing a child of a vfork() that had not yet exec'ed a new image from performing an mmap() operation has been removed, provided that the child process is an ELF-based process. There is now no restriction on the placement of new maps; they can be created at any place in the 3 GB user virtual space, without penalty. The maximum per-process limit on the number of maps created via either mmap() or shmat() has been raised from 12 to in excess of 3500. As mentioned in the DIAGNOSTICS section, callers of mmap() should be careful to not cast the mmap() return value to an integer and then test the resulting value for < 0 as a means of detecting failure. The size of user virtual space can make the address returned by mmap() appear negative when viewed as a signed integer. This, however, is not an issue for previously existing COFF linker format based executables, as all such executables are run in a one gigabyte (1GB) compatibility-mode address space. In V4.0, all ELF-based binaries run with a three gigabyte (3GB) address space, hence the danger in treating addresses returned from mmap() as signed integer values. QEXEC(2SEQ) DYNIX/ptx QEXEC(2SEQ) NAME qexec: qexecl, qexecv, qexecle, qexecve, qexeclp, qexecvp - execute a file SYNOPSIS #include #include int qexecl (qsetp, flags, file, arg0, arg1, ..., argn, (char *)0) quadset_t *qsetp; int flags; char *file, *arg0, *arg1, ..., *argn; int qexecle (qsetp, flags, file, arg0, arg1, ..., argn, (char *)0, envp) quadset_t *qsetp; int flags; char *file, *arg0, *arg1, ..., *argn, *envp[]; int qexeclp (qsetp, flags, file, arg0, arg1, ..., argn, (char *)0) quadset_t *qsetp; int flags; char *file; char *arg0, *arg1, ..., *argn; int qexecv (qsetp, flags, file, argv) quadset_t *qsetp; int flags; char *file, *argv[]; int qexecve (qsetp, flags, file, argv, envp) quadset_t *qsetp; int flags; char *file, *argv[], *envp[]; int qexecvp (qsetp, flags, file, argv) quadset_t *qsetp; int flags; char *file, *argv[]; DESCRIPTION The qexec variants operate the same as their corresponding variations of exec (see exec(2)), with the addition of specified quad placement. The caller can specify a suitable quad or set of quads where the process should be located either through the qsetp argument or by setting the QUAD_ATTACH_TO_PARENT flag in the flags argument. If the qsetp argument is used to specify suitable quads, qsetp points to a quadset_t that identifies the quad or quads that are acceptable for the process. A suitable quad or set of quads can be identified using quad_loc(2SEQ), and can be manipulated using the operators described in quademptyset(2SEQ). If more than one quad is specified by qsetp , the process will be loaded on the best of the quads, taking CPU load, memory availability and other factors into account. Unless the QUAD_INSIST bit in flags is set, the set of quads specified by qsetp is considered a hint, which may be overridden in extreme cases if all the quads in the specified quad set have very high CPU loads or too little available memory. If the QUAD_INSIST bit is included in the flags argument, the quad specification is treated as "mandatory," and the process is loaded on one of the specified quads despite a large CPU load or memory shortage. Once the process has been loaded, using the qsetp argument with qexec has the same effect as using the R_QUAD option of attach_proc(2SEQ) to attach the process to a set of quads. If the set contains more than one quad, the process may migrate among the quads in the set for load-balancing purposes. If the QUAD_INSIST bit in flags is not set, the process may also migrate to a quad outside the specified set of quads under the above extreme conditions. It is advisable that QUAD_INSIST be used with considerable caution. Situations are rare in which a process will perform better at a quad where a specific resource is located than at some other quad even under extreme CPU or memory overload conditions. For example, being located on the same quad as an important resource is of little value to a process that has been swapped out due to an extreme memory overload, or that is being starved for CPU bandwidth under an extreme CPU overload. If the qsetp argument is used to specify suitable quads, the caller can further specify an appropriate quad by setting the QUAD_SMALLMEM or QUAD_LARGEMEM bits in the flags argument. QUAD_SMALLMEM indicates that the process will have very low memory requirements, so can be placed on a quad having little available memory if that quad has a particularly light CPU load. Conversely, if QUAD_LARGEMEM is set, the process is placed on the quad with the most available memory even though that quad may have a high CPU load. QUAD_SMALLMEM and QUAD_LARGEMEM are also taken into account during any future process migrations. Alternatively, when using qexec, the user can specify a suitable quad for the process by setting the QUAD_ATTACH_TO_PARENT bit in the flags argument. If the QUAD_ATTACH_TO_PARENT flag is set, the process is loaded on the quad where its parent process is currently located. Once the process has been loaded, using the QUAD_ATTACH_TO_PARENT bit with qexec has the same effect as using the R_PID option of attach_proc(2SEQ) to attach the process to its parent. If either the child or parent process migrates to another quad for load-balancing purposes, the other process will accompany it. Both processes will always be located on the same quad, until one either detaches or exits. If the QUAD_ATTACH_TO_PARENT flag is set, the qsetp argument is ignored, as are the QUAD_SMALLMEM and QUAD_LARGEMEM flags. ERROR VALUES In addition to the errors of exec(2), the qexec call will fail, setting errno accordingly, and return without loading the specified process when one or more of the following are true: [EFAULT] A bad address was supplied for qsetp. [EINVAL] No quads have been specified in qsetp. [EINVAL] Both QUAD_SMALLMEM and QUAD_LARGEMEM were specified in flags. [EINVAL] There is a mandatory quad requirement that is not compatible with the process' run queue, i.e., the run queue does not have engines scheduling from it that are in the process' mandatory quad requirement. [ENXIO] No existing quads have been specified in qsetp. DIAGNOSTICS see exec(2) THREAD-SAFETY NOTES qexecl, qexecle, qexeclp, qexecv, qexecve, qexecvp: Thread-safe. SEE ALSO exec(2), fork(2), quad_loc(2SEQ), quademptyset(2SEQ), attach_proc(2SEQ), detach_proc(2SEQ) QFORK(2SEQ) DYNIX/ptx QFORK(2SEQ) NAME qfork, shfork, shqfork - create a new process SYNOPSIS #include #include pid_t shfork (uint_t flags) pid_t qfork (quadset_t *attach_qsetp, uint_t flags) pid_t shqfork (quadset_t *attach_qsetp, uint_t flags) DESCRIPTION qfork causes creation of a new process. The new process (child process) is an exact copy of the calling process (parent process). This means the child process inherits the following attributes from the parent process: environment close-on-exec flag (see exec(2)) signal handling settings (i.e., SIG_DFL , SIG_IGN , SIG_HOLD , function address) set-user-ID mode bit set-group-ID mode bit profiling on/off status nice value (see nice(2)) all attached shared memory segments (see shmop(2)) all attached mapped regions (see mmap(2SEQ)) process group ID session ID foreground process ID (see exit(2)) current working directory root directory file mode creation mask (see umask(2)) file size limit (see ulimit(2)) The child process differs from the parent process in the following ways: The child process has a unique process ID. The child process has a different parent process ID (i.e., the process ID of the parent process). When using fork and qfork, the child process has its own copy of the parent's file descriptors. Each of the child's file descriptors shares a common file pointer with the corresponding file descriptor of the parent. However, if shfork or shqfork is used, the child process may share the parent's file descriptors (more below on these variations of fork). All semadj values are cleared (see semop(2)). Process locks, text locks and data locks are not inherited by the child (see plock(2)). The child process's utime, stime, cutime, and cstime are set to 0. The time left until an alarm clock signal is reset to 0. qfork is used when the caller wishes to specify the quad or set of quads where the child process should be located. The caller can specify suitable quads either through the attach_qset argument or by setting the QUAD_ATTACH_TO_PARENT flag in the flags argument. If the attach_qset argument is used to specify suitable quads, attach_qset points to a quadset_t that identifies the quad or quads that are acceptable for the process. A suitable quad or set of quads can be identified using quad_loc(2SEQ), and can be manipulated using the operators described in quademptyset(2SEQ). If more than one quad is specified by attach_qset , the process will be loaded on the best of the quads, taking CPU load, memory availability and other factors into account. Unless the QUAD_INSIST bit in flags is set, the set of quads specified by attach_qset is considered a hint, which may be overridden in extreme cases if all the quads in the specified quad set have very high CPU loads or too little available memory. If the QUAD_INSIST bit is included in the flags argument, the quad specification is treated as "mandatory," and the child process is loaded on one of the specified quads despite a large CPU load or memory shortage. Once the process has been loaded, using the attach_qset argument with qfork has the same effect as using the R_QUAD option of attach_proc(2SEQ) to attach the child process to a set of quads. If the set contains more than one quad, the process may migrate among the quads in the set for load-balancing purposes. If the QUAD_INSIST bit in flags is not set, the process may also migrate to a quad outside the specified set of quads under the above extreme conditions. It is advisable that QUAD_INSIST be used with considerable caution. Situations are rare in which a process will perform better at a quad where a specific resource is located than at some other quad even under extreme CPU or memory overload conditions. For example, being located on the same quad as an important resource is of little value to a process that has been swapped out due to an extreme memory overload, or that is being starved for CPU bandwidth under an extreme CPU overload. If the attach_qset argument is used to specify suitable quads, the caller can further specify an appropriate quad by setting the QUAD_SMALLMEM or QUAD_LARGEMEM bits in the flags argument. QUAD_SMALLMEM indicates that the child will have very low memory requirements, so can be placed on a quad having little available memory if that quad has a particularly light CPU load. Conversely, if QUAD_LARGEMEM is set, the process is placed on the quad with the most available memory even though that quad may have a high CPU load. QUAD_SMALLMEM and QUAD_LARGEMEM are also taken into account during any future process migrations. Alternatively, when using qfork, the user can specify a suitable quad for the child process by setting the QUAD_ATTACH_TO_PARENT bit in the flags argument. If the QUAD_ATTACH_TO_PARENT flag is set, the child process is loaded on the quad where the parent process is currently located. Once the child process has been loaded, using the QUAD_ATTACH_TO_PARENT bit with qfork has the same effect as using the R_PID option of attach_proc(2SEQ) to attach the child to its parent. If either the child or parent process migrates to another quad for load-balancing purposes, the other process will accompany it. Both processes will always be located on the same quad, until one either detaches or exits. If the QUAD_ATTACH_TO_PARENT flag is set, the attach_qset argument is ignored, as are the QUAD_SMALLMEM and QUAD_LARGEMEM flags. shfork operates the same as fork, but allows the child process to share the parent processes file descriptors instead of just copying them. To enable the file descriptor sharing, the FM_SHARE_OFILE bit must be set in flags. If this flag is not set, shfork will act exactly the same as fork. shqfork allows for the same operation as qfork along with the shared file descriptors of shfork. As with shfork, the FM_SHARE_OFILE flag must be set to enable the sharing. FLAG VALUES The following bit patterns are valid values for the flags argument. for use with shfork and shqfork: FM_SHARE_OFILE 0x0002 share open file table for use with qfork and shqfork: QUAD_INSIST 0x00000010 mandatory quad placement QUAD_SMALLMEM 0x00000020 requires little memory QUAD_LARGEMEM 0x00000040 requires lots of memory ERROR VALUES qfork fails and no child process is created if one or more of the following are true: [EAGAIN] The system-imposed limit on the total number of processes under execution would be exceeded. [EAGAIN] The system-imposed limit on the total number of processes under execution by a single user would be exceeded. [EAGAIN] There is insufficient swap space available for the child process. [EFAULT] A bad address was supplied for attach_qsetp. [EINVAL] No quads have been specified in attach_qsetp. [EINVAL] Both QUAD_SMALLMEM and QUAD_LARGEMEM were specified in flags. [EINVAL] There is a mandatory quad requirement that is not compatible with the parent's run queue, i.e., the run queue does not have engines scheduling from it that are in the child's mandatory quad requirement. [EINVAL] The parent's run queue has changed since the child was assigned to a quad and is no longer compatible with the child's mandatory quad requirement. [ENXIO] No existing quads have been specified in attach_qsetp. [ENFILE] File table overflow when attempting to allocate child processes open file-table for file descriptors. THREAD-SAFETY NOTES qfork, shfork, shqfork: Thread-safe. SEE ALSO exec(2), nice(2), plock(2), ptrace(2), semop(2), shmop(2), signal(2), sigset(2), sigaction(2), times(2), ulimit(2), umask(2), wait(2), attach_proc(2SEQ), detach_proc(2SEQ), quad_loc(2SEQ), quademptyset(2SEQ) DIAGNOSTICS Upon successful completion, shfork, qfork, and shqfork return a value of 0 to the child process and return the process ID of the child process to the parent process. Otherwise, a value of -1 is returned to the parent process, no child process is created, and errno is set to indicate the error. BCS DIFFERENCES For BCS processes, any signals pending for the parent are propagated to the the child. Normally, these would be cleared in the child image. BUGS To avoid file inconsistencies when using stdio(3S) and qfork together, always call fflush(3S) on open file descriptors (even read-only ones) before doing a qfork call. QUAD_LOC(1M) DYNIX/ptx QUAD_LOC(1M) NAME quad_loc - find the quads at which the specified resource is located SYNOPSIS quad_loc -f path quad_loc -p pid quad_loc -m shmid quad_loc -M shmkey DESCRIPTION quad_loc lists a quad or a set of quads where the specified resource is located. The resource is specified as follows: -f path Returns the quad or set of quads that are 'nearest' to the resource specified by path. For example, if path specifies a file, quad_loc returns the quad or set of quads that are able to dma directly to the disk on which the file is located. If path specifies a device, quad_loc returns the quad or set of quads that have efficient access to that device. quad_loc works similarly if path specifies a socket, FIFO or remote file. -p pid Returns the quad on which the process specified by pid currently resides. -m shmid Returns the quad or set of quads which may contain memory pages that are part of the shared memory segment specified by the shared memory identifier shmid. -M shmkey Returns the quad or set of quads which may contain memory pages that are part of the shared memory segment specified by the key shmkey. EXIT STATUS quad_loc may fail and exit with status 1 through 4 if invoked with bad or insufficient arguments, or with status 5 if it failed to return the list of quads associated with the given resource. The exit status is 0 upon successful completion. BUGS If path specifies something other than a block or character special device, the -f option returns a list of all quads present in the system. There is no way to tell the difference between this case and the case where the device is directly accessible from all quads. SEE ALSO attach_proc(1M) quad_loc(2SEQ) QUADEMPTYSET(2SEQ) DYNIX/ptx QUADEMPTYSET(2SEQ) NAME quademptyset, quadfillset, rgn_quadfillset, quadaddset, quaddelset, quadismember, quadisemptyset, quadandset, quadorset, quaddiffset - manipulate sets of quads SYNOPSIS #include #include int quademptyset (set) quadset_t *set; int quadfillset (set) quadset_t *set; int rgn_quadfillset (set, rgnname) quadset_t *set; const char* rgnname; int quadaddset (set, quadno) quadset_t *set; int quadno; int quaddelset (set, quadno) quadset_t *set; int quadno; int quadismember (set, quadno) quadset_t *set; int quadno; int quadisemptyset (set) quadset_t *set; int quadandset (set1, set2) quadset_t *set1, *set2; int quadorset (set1, set2) quadset_t *set1, *set2; int quaddiffset (set1, set2) quadset_t *set1, *set2; DESCRIPTION The quadsetops primitives manipulate sets of quads. They operate on data objects of type quadset_t. The quademptyset function initializes the quad set pointed to by set, such that no quads are included in the set. The quadfillset function initializes the quad set pointed to by set, such that all quads that are currently configured in the caller's region are included in the set. The rgn_quadfillset function initializes the quad set pointed to by set, such that all quads that are currently configured in the region rgnname are included in the set. If rgnname is NULL then rgn_quadfillset initializes the quadset pointed to by set, such that all quads that are currently configured in the caller's region are included in the set. Applications should call either quademptyset or quadfillset at least once for each object of type quadset_t prior to any other operation on the object. If such an object is not initialized in this way, but is supplied as an argument to any of the quadaddset, quaddelset, quadismember, quadandset, quadorset, quaddiffset, qfork, qexec, etc. functions, the results are undefined. The quadaddset and quaddelset functions respectively add and delete the individual quads specified by the value of quadno from the quad set pointed to by the argument set. The quadandset and quadorset functions respectively perform logical and and or operations on the quad sets pointed to by the arguments set1 and set2, storing the result in the quad set pointed to by set1. The quaddiffset function finds the logical difference (the members that are contained in the first set but not in the second set) between the quad sets pointed to by the arguments set1 and set2. The result is stored in the quad set pointed to by set1. The quadismember function tests whether the quad specified by the value of quadno is a member of the set pointed to by the argument set, and the quadisemptyset function tests whether the quad set pointed to by the argument set is empty. DIAGNOSTICS On successful completion, the quadismember function returns a value of one if the specified quad is a member of the specified set, or a value of zero if it is not. Similarly, the quadisemptyset function returns a value of one if the quad set pointed to by the argument set is empty, or a value of zero if it is not. On successful completion, the other functions return a value of zero. If an error is detected for any of the above functions, a value of -1 is returned and errno is set to indicate the error. If the following condition is detected, quadaddset, quaddelset, and quadismember return -1 and set errno to the corresponding value: [EINVAL] The value of quadno is an invalid or unsupported quad number. If the following condition is detected, rgn_quadfillset return -1 and set errno to the corresponding value: [ENOENT] region name specified in rgnname is not valid or currently not active. [EFAULT] The buffer pointed to by set points to an address outside the valid address space of the process. NOTES These are Sequent library routines. To use them, specify the -lseq option to link with the Sequent library. Since these are Sequent extensions, code using these routines may not be portable to other systems. THREAD-SAFETY NOTES quadaddset, quadandset, quaddelset, quaddiffset, quademptyset, quadfillset, quadisemptyset, quadismember, quadorset, rgn_quadfillset: Thread-safe. SHMGET(2) DYNIX/ptx SHMGET(2) NAME shmget, shmgetq, shmgetv - get shared memory segment identifier SYNOPSIS #include #include #include int shmget (key, size, shmflg) key_t key; int size, shmflg; int shmgetq (key, size, shmflg, qds) key_t key; int size, shmflg; quadset_t *qds; int shmgetv (key, size, shmflg, shmvcnt, shmv) key_t key; size_t size, int shmflg, shmvcnt; shmvec_t *shmv; DESCRIPTIONS shmget shmget returns the shared memory identifier associated with key. A shared memory identifier, associated data structure, and shared memory segment of at least size bytes (or size pages when SHM_VIRTWIN is specified; see intro(2) and later discussion below), are created for key if one of the following is true: key is equal to IPC_PRIVATE. key does not already have a shared memory identifier associated with it, and (shmflg & IPC_CREAT) is true. Upon creation, the data structure associated with the new shared memory identifier is initialized as follows: shm_perm.cuid, shm_perm.uid, shm_perm.cgid, and shm_perm.gid are set equal to the effective user ID and effective group ID, respectively, of the calling process. The low-order 9 bits of shm_perm.mode are set equal to the low-order 9 bits of shmflg. shm_segsz is set equal to the value of size. shm_lpid, shm_nattch, shm_atime, and shm_dtime are set equal to 0. shm_ctime is set equal to the current time. DYNIX/ptx extends the standard System V implementation of shmget(2) by the addition of five special flags. The first of these is named SHM_HARDLOCK. When the SHM_HARDLOCK flag is OR'd with IPC_CREAT in the shmflg argument, the resulting shared memory segment will be hard-locked in physical memory. The segment will never be swapped and the pages of the shared segment will never be paged-out. All the physical memory required for the segment is allocated before shmget(2) returns. The second flag extension is SHM_VIRTWIN; it cannot be specified unless SHM_HARDLOCK is also specified. The presence of SHM_VIRTWIN and SHM_HARDLOCK in the shmflg argument indicates that all pages in the hard-locked segment are to be "virtually-windowed" by all processes that attach to the segment. That is, the region of user virtual space created by the shmatvw(2SEQ) call (when attaching to a shared segment created with SHM_VIRTWIN and SHM_HARDLOCK) will act as a "window." Any number of virtual pages within that "window" can be dynamically remapped via virtwin(2SEQ) to address any specific pages within the (typically much larger) underlying shared segment. Furthermore, the presence of SHM_VIRTWIN in shmflg causes shmget(2) to treat the size argument as the number of pages (not the number of bytes as would ordinarily be the case) to be contained in the resulting shared memory segment. (The size of each individual page in bytes, allocated when SHM_VIRTWIN is specified, is that returned by an invocation of sysconf(2) with the _SC_PAGE_SIZE parameter.) Thus, while the SHM_VIRTWIN flag can be used to create very small segments (even those comprised of a single page), its typical use is to create enormous shared memory segments (often limited in size only by the physical memory of the machine), and often larger than the amount of user virtual space a process can devote to accessing the segment. Besides avoiding the overhead of possibly swapping and/or paging the pages of the shared segment, segments created with the SHM_HARDLOCK flag in the absence of SHM_VIRTWIN cause all processes which attach to them via shmat(2) to share the same page table resources. This latter characteristic of SHM_HARDLOCK requires that the size of a hard-locked segment, specified in the size argument, be an even multiple of the amount of memory representable by one page table. This value can be determined from the _SC_LARGE_PAGE_SIZE parameter of the sysconf(2) system call. Also, when attaching a non-virtually-windowed hard-locked shared segment to a process' address space (via shmat(2)), the caller must either let the system choose the attach address or select an address that is an even multiple of _SC_LARGE_PAGE_SIZE. (The _SC_FREEMEM and _SC_PHYSMEM parameters of the sysconf(2) system call can be used to determine the desired size of a non-virtually-windowed hard-locked shared memory segment.) Since the page table resources used when shmat(2) is employed to attach to a non-virtually-windowed hard-locked shared segment are themselves shared, operations that change the attributes of a shared hard-locked memory region, and consequently the page table entries, must be disallowed. Thus, mprotect(2) operations on hard-locked segments are disallowed. When SHM_VIRTWIN is specified in addition to SHM_HARDLOCK, shmat(2) cannot be used to attach to the segment. Instead, shmatvw(2SEQ) must be used. The resulting page-table resources are not shared and are instead unique to each process, since the underlying segment is virtually-windowed by each process that attaches to it. The use of SHM_VIRTWIN thus eliminates all alignment and size constraints on the segment size and attach address, at the expense of requiring unique page-table resources for each process sufficient for the size of the virtual region chosen to virtually-window the shared segment. Finally, irrespective of whether SHM_VIRTWIN is specified, care must be taken when specifying SHM_HARDLOCK to avoid degrading overall system throughput, since physical memory dedicated to hard-locked shared segments cannot be used for any other purpose until the segment is removed. Thus, only processes with either root or PRIV_VM privilege are capable of creating hard-locked shared memory segments. However, any process with access rights to an existing hard-locked shared segment (via the shm_perm.mode bits) can attach it to its address space. The SHM_HARDLOCK feature is disabled by default to protect against indiscriminate use. The SHM_HARDLOCK (and SHM_VIRTWIN) features can be enabled via the SHM_LOCK_OK system configuration parameter (settable via the menu system by the system administrator). The remaining flag extensions are used to control the paging policy that affects which quad pages for the shmget() segment come from. These flags have no affect if SHM_HARDLOCK is specified. SHM_FIRSTREF Allocate the pages on the quad that makes the first reference to the page SHM_MOSTFREE Allocate the pages on the quad with the most free memory. SHM_DISTRIBUTE Allocate the pages evenly across all quads. Only one of SHM_FIRSTREF, SHM_MOSTFREE and SHM_DISTRIBUTE can be specified and if none is specified then SHM_DISTRIBUTE is assumed. SEQUENT API EXTENSIONS In addition to the Sequent flag extensions of SHM_HARDLOCK and SHM_VIRTWIN and the paging policy flags, DYNIX/ptx provides two additional API's named shmgetq(2SEQ) and shmgetv(2SEQ). These are described below. shmgetq shmgetq(2SEQ) behaves the same as shmget(2) with the addition of a qds parameter used to specify a quadset to restrict the set of quads the paging policy flags affect. By default shmget(2) assumes a quadset containing all the quads in the system. See quademptyset(2SEQ) for information on constructing quadsets. shmgetv shmgetv(2SEQ), like shmgetq(2SEQ), allows the caller to restrict the set of quads the paging policy flags affect, but also allows multiple shared page segment requests to be made in a single shmgetv(2SEQ) call. shmgetv(2SEQ) is intended to be used with SHM_HARDLOCK segments, though not restricted to them. The shmvcnt parameter gives the number of shmvec_t entries pointed to by shmv. shmv points to a list of shmvec_t structures describing sub-segments of the total shared memory segment request size. The shmvec_t structure contains the following members: size_t shm_off; /* offset into total shm region */ size_t shm_size; /* size of this shm segment */ quadset_t shm_qds; /* quadset allocation for segment */ Each shm_off entry describes the beginning offset of that particular sub-segment within the total shared segment size. The shm_size entry describes the size of that particular sub-segment. Each shm_qds entry describes the quadset from which to allocate the pages for that sub-segment. If the quadset is empty a quadset of all quads in the system is assumed. See quademptyset(2SEQ) for information on constructing quadsets. By default size, shm_off, and shm_size are specified in bytes and each must be a multiple of the system page size as specified by a call to sysconf(2) with the _SC_PAGE_SIZE parameter. As shmget(2) describes, if both SHM_HARDLOCK and SHM_VIRTWIN are specified size, shm_off, and shm_size will be treated as the number of pages (not the number of bytes). If SHM_HARDLOCK is specified and SHM_VIRTWIN is not size must be an even multiple of the amount of memory represented by one page table, which can be determined from a call to sysconf(2) with the _SC_LARGE_PAGE_SIZE parameter. shmgetv has the following unique characteristics and requirements: Not all segments of the requested total size shared memory segment need to be specified. Any missing sub- segment in the shmv list will be filled in and allocated using the default policy. The size parameter must be no less than the sum of all shm_size entries including missing segments. If the size parameter is greater than that sum an additional segment will be allocated at the end of the last specified segment. The shmv list does not have to be in offset order. A quad can be listed in more than one shmv sub-segment. The shmv segments specified by shm_off and shm_size must not overlap each other. A list of more than one shmvec_t requires SHM_HARDLOCK be specified. DIAGNOSTICS Upon successful completion, a non-negative integer, namely a shared memory identifier is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error. shmget fails if any of the following are true: [EACCES] A shared memory identifier exists for key, but operation permission (see intro(2)) as specified by the low-order 9 bits of shmflg would not be granted. [EAGAIN] Swap space required to back up the memory being allocated is temporarily unavailable. [EEXIST] A shared memory identifier exists for key but ((shmflg & IPC_CREAT) and (shmflg & IPC_EXCL)) is true. [EINTR] The shmget system call was interrupted by a signal. [EINVAL] size is less than the system-imposed minimum or greater than the system-imposed maximum. [EINVAL] A shared memory identifier exists for key but the size of the segment associated with it is less than size and size is not equal to zero. [EINVAL] The SHM_VIRTWIN flag was specified in the absence of the SHM_HARDLOCK flag. SHM_VIRTWIN requires the segment to be hard-locked as well, via SHM_HARDLOCK. [EINVAL] A shared memory identifier exists for key, but the caller specified SHM_VIRTWIN while the existing shared memory segment matching the identifier is not virtually-windowed. Alternatively, the caller did not specify SHM_VIRTWIN while the existing shared memory identifier matching the identifier is virtually-windowed. [EINVAL] The SHM_HARDLOCK flag was specified in the absence of SHM_VIRTWIN, but size is not a multiple of _SC_LARGE_PAGE_SIZE. [EINVAL] The SHM_HARDLOCK flag was specified, and the hard-locked shared segments feature is not enabled via the SHM_LOCK_OK configuration parameter. [EINVAL] For shmgetq, more than one of SHM_FIRSTREF, SHM_MOSTFREE, or SHM_DISTRIBUTE were set. [EINVAL] For shmgetq, none of SHM_FIRSTREF, SHM_MOSTFREE, or SHM_DISTRIBUTE were set. [EINVAL] For shmgetq, the quadset in qds is either empty or not a proper subset of the quads available in the system. [EFAULT] For shmgetq, qds points outside the allocated address space of the process. [EINVAL] For shmgetv, shmvcnt is less than or equal to zero. [EFAULT] For shmgetv, shmv points outside the allocated address space of the process. [EINVAL] For shmgetv, shmvec_t entries specify overlapping shm_off/ shm_size values. [EINVAL] For shmgetv, more than one shmvec_t segment was requested or needs to be allocated but SHM_HARDLOCK was not specified. [EINVAL] For shmgetv, the total size of the allocation based on the shmvec_t list (after any missing segments were allocated) is greater than the total requested size. [EINVAL] For shmgetv, a shm_qds entry is nonzero and not a proper subset of the quads available on the system. [EINVAL] For shmgetv, SHM_VIRTWIN is not specified, and size or a shm_size or shm_off entry is not a multiple of the system page size. [ENOENT] A shared memory identifier does not exist for key and (shmflg & IPC_CREAT) is false. [ENOMEM] A shared memory identifier and associated shared memory segment are to be created but the amount of available memory is not sufficient to fill the request. [ENOSPC] A shared memory identifier is to be created but the system-imposed limit on the maximum number of allowed shared memory identifiers system wide would be exceeded. [EPERM] The SHM_HARDLOCK flag was specified but the caller did not have sufficient privilege. NOTES The user must explicitly remove shared memory segments after the last reference to them has been removed. shmgetq(2SEQ) and shmgetv(2SEQ) are Sequent library routines. To use them, specify the -lseq option to link with the Sequent library. Since this is a Sequent extension, code using these routines may not be portable to other systems. THREAD-SAFETY NOTES shmget, shmgetq, shmgetv: Thread-safe. SEE ALSO intro(2), shmctl(2), shmop(2), shmatvw(2SEQ), virtwin(2SEQ), ftok(3C), quademptyset(2SEQ) SHOWQUADS(1M) DYNIX/ptx SHOWQUADS(1M) NAME showquads - show quad information SYNOPSIS /etc/showquads DESCRIPTION showquads displays a table containing information about all the quads in a system. For each quad, the quad number, total memory, and private memory are displayed. The total memory doesn't include private memory. For each processor associated with a quad, the following information is also displayed: processor number, type, speed, SLIC address, state, and FPA status. For P6 processors, the AGENT ID is also displayed. For quads, the memory displayed is in megabytes. The speed that is displayed is the CPU rate in MHz. A processor's state is either online or offline. The FPA field indicates with a yes or no whether a Floating Point Accelerator is present; emu indicates that an FPA is emulated in software. SEE ALSO online(1M), noage(1M), showcfg(1M), tmp_ctl(2SEQ), showprocs(1M) TMP_AFFINITY(2SEQ) DYNIX/ptx TMP_AFFINITY(2SEQ) NAME tmp_affinity - bind a process to a processor SYNOPSIS #include int tmp_affinity(processor); int processor; DESCRIPTION tmp_affinity allows a process to be bound to a specified logical processor. Processor numbers start at zero and are numbered contiguously. Deconfigured processors are not included. The previous affinity is returned. The process must have PRIV_REGION vectored privilege to be bound to a processor which does not belong to the region to which the process belongs. On a successful bind, if the process belongs to the system region, then it stays in the system region, otherwise it moves to the user defined region to which the processor belongs. If the processor argument is AFF_NONE, the process is realeased from any previous affinity (that is, allowed to migrate within its region). If the processor argument is AFF_QUERY, the current affinity, or AFF_NONE is returned, without changing the current affinity. You must have the PRIV_SCHED vectored privilege to change affinity. Affinity is inherited across the fork(2) and exec(2) system calls. DIAGNOSTICS If successful, either the previous affinity processor number or AFF_NONE is returned. On error, -1 is returned and errno is set to indicate the error. ERRORS The tmp_affinity fails if: [ENODEV] processor is either offline or bad. [ENXIO] processor is out of range. [EPERM] Process does not have the appropriate permissions. SEE ALSO tmp_ctl(2SEQ), online(1M), priv_ctl(2SEQ), rgnstat(1M) NOTES This is a Sequent library routine. To use it, specify the -lseq option to link with the Sequent library. Since this is a Sequent extension, code using this routine may not be portable to other systems. THREAD-SAFETY NOTES tmp_affinity: Thread-safe. ATTACH_PROC(1M) DYNIX/ptx ATTACH_PROC(1M) NAME attach_proc - attach a process to a quad SYNOPSIS attach_proc [-i] -p pid attach_proc [-i] -f path [args...] DESCRIPTION The specified process is attached to one of the quads in the specified set of quads. quad_list is a list of quad IDs that are separated by spaces. The result of attaching a process to a set of quads is that: (1) The process' memory image is migrated to one of the quads in quad_list if it does not already reside there. (2) The process is ineligible for future automatic migrations from the set of quads until it is explicitly detached. If quad_list has more than one quad, the system heuristically chooses the best quad from that set to attach the process to. Note that the process' run queue must include processors on at least one of the specified quads. If no processors on any of these quads schedule from the process' run queue, attach_proc fails to attach the process. In that case, to allow the process to be attached to the desired quads, either the process must be reassigned to a run queue having processors on at least one of the desired quads or processors on at least one of the desired quads must be added to the process' run queue (see the 'assign' and 'change' options of rqadmin(1M)). The attach_proc command has the following options: -i Insist that the attachment take place; otherwise, attach_proc is assumed to be advisory. -f filename Execute filename on one of the specified quads. filename must be an executable file. -p pid Migrate the process having process ID number pid to one of the specified quads. The specified process must belong to the current user unless the current user is the superuser. EXIT STATUS When invoked with the -p option, attach_proc exits with status 0 upon successful completion, or with status 5 if it failed to migrate the process. When invoked with the -f option, attach_proc exits with the status of the command specified by the argument file if it's successfully executed. Otherwise, it returns with status 127 if the command file was not found, or with status 126 if it failed to execute the file. SEE ALSO detach_proc(1M), quad_loc(1M), attach_proc(2SEQ)