HP-UX 11i v3 Memory Management Subsystem

17
Tuning ninode does not affect the JFS inode cache, which is maintained separately from the HFS inode cache. If
your only HFS file system is
/stand, then ninode can usually be tuned to a low value, for example, 400.
By default, the JFS inode cache is dynamic in size: it grows and shrinks as needed. However, since the inodes are
freed to the kernel memory allocator’s free object chain, the memory may not be available for use for other reasons
(except for other same-sized memory allocations). The freed inodes on the object free-lists are still considered
“used” system memory. Also, the kernel memory allocations and subsequent frees add additional overhead to the
kernel.
The dynamic nature of the JFS inode cache does not provide much benefit with the current kernel memory allocator.
Using a statically sized JFS inode cache has the advantage of keeping inodes in the cache longer and reducing the
overhead of continued kernel memory allocations and frees. Instead, the unused inodes are retained on the JFS
inode cache free-list chains. If you need to bring a new JFS inode in from disk, JFS uses the oldest inactive inode.
Using a static JFS inode cache also avoids long kernel memory object free chains for each processor. Another
benefit to a static JFS inode cache is that the
vxfsd daemon will not use as much processor time trimming the size
of the JFS inode cache, which can be considerable on large-memory systems.
Beginning with HP-UX 11i v2 (with JFS 3.5 and above) a new system-wide tunable vxfs_ifree_timelag was
introduced to vary the length of time an inode stayed in the cache before it is considered for removal. Setting
vxfs_ifree_timelag to -1 effectively makes the JFS inode cache a static cache. Setting
vxfs_ifree_timelag is especially useful on large-memory systems so the vxfsd daemon does not use too
much processor time. The following example uses
kctune to change vxfs_ifree_timelag without a reboot:
# kctune vxfs_ifree_timelag=-1
Tunable Value Expression Changes
vxfs_ifree_timelag (before) 0 Default Immed
(now) -1 -1
Considerations for application developers
This section contains information about the ways in which an application program is constructed can interact with
the properties of the memory management subsystem.
Addressing model
The virtual address space presented to applications is flat and contiguous -- 4 gigabytes in size for 32-bit
applications and 16 exabytes for 64-bit applications. The virtual memory subsystem, in conjunction with the
compiler and linker, impose an addressing model to govern usage of certain parts of the address space. In
particular, the addressing model may restrict the range of virtual addresses that can be used for memory objects
that are shared among processes.
The Mostly Private Address Space (MPAS) model gives the most flexibility in the usage of the address space, which
can be crucial for 32-bit applications accessing large memory objects. The added flexibility came at the expense of
significant performance cost, which was remedied to a great extent in the March 2010 Update.
An application can be built to use the MPAS model by specifying the +as mpas option to the linker, ld(1).
After being built, an application can be converted to MPAS by giving the same option to the
chatr(1) command.
Local memory
Hardware platforms that have a NUMA structure can be configured with a mixture of local memory and interleaved
memory. Application programs can provide hints to request that their memory objects be placed in the interleaved
locality, the current locality, or the locality of the first processor to touch the memory. For shared memory objects,
the
shmget(2) call allows the memory hint to be specified in the flags field. For memory mapped files, the
corresponding interface is
mmap(2).