AIX Page Replacement

The AIX page replacement daemons scan memory a page at a time to find pages to evict in order to free up memory.

minperm and maxperm

These tunable parameters are used to indicate how much memory the AIX kernel should use to cache non-computational pages.

The maxperm tunable parameter indicates the maximum amount of memory that should be used to cache non-computational pages.

By default, maxperm is an "un-strict" limit, meaning that the limit can be exceeded.

Making maxperm an un-strict limit allows more non-computational files to be cached in memory when there is available free memory.

The maxperm limit can be made a "strict" limit by setting the strict_maxperm tunable parameter to 1.

When maxperm is a strict-limit, the kernel does not allow the number of non-computational pages to exceed maxperm, even if there is free memory available.


The minperm limit indicates the target minimum amount of memory that should be used for non-computational pages.

The number of non-computational pages is referred to as numperm:

The vmstat –v command displays the numperm value for a system as a percentage of a system’s real memory.

When  the number of non-computational pages (numperm) is greater than or equal to maxperm, the AIX page replacement daemons strictly target non-computational pages.

When the number of non-computational pages (numperm) is less than or equal to minperm, the AIX page replacement daemons target both computational and non-computational pages
.

When the number of non-computational pages (numperm) is between minperm and maxperm, the lru_file_repage tunable parameter controls what kind of pages the AIX page replacement daemons should steal.

When numperm is between minperm and maxperm, the AIX page replacement daemons determine what type of pages to target based on their internal re-paging table when the lru_file_repage tunable parameter is set to 1.
# vmstat -v


20.0 minperm percentage <<- system’s minperm% setting
80.0 maxperm percentage <<- system’s maxperm% setting

AIX Virtual Memory Manager

The AIX® virtual memory manager (AIX VMM) is a page-based virtual memory manager.

A page is a fixed-size block of data.

A page might be resident in memory (that is, mapped into a location in physical memory), or a page might be resident on
a disk (that is, paged out of physical memory into paging space or a file system).

AIX maps pages into real memory based on demand.

When an application references a page that is not mapped into real memory, the system generates a page fault.

To resolve the page fault, the AIX kernel loads the referenced page to a location in real memory.

If the referenced page is a new page (that is, a page in a data heap of the process that has never been previously referenced), "loading" the referenced page simply means filling a real memory location with zeros (that is, providing a zero-filled page).

If the referenced page is a pre-existing page (that is, a page in a file or a previously paged out page), loading the referenced page involves reading the page from the disk (paging space or disk file system) into a location in real memory.


Once a page is loaded into real memory, it is marked as unmodified.

If a process or the kernel modifies the page, the state of the page changes to modified.

This allows AIX to keep track of whether a page has been modified after it was loaded into memory.

As the system adds more pages into real memory, the number of empty locations in real memory that can contain pages decreases.

When the number of free page  frames gets to a low value, the AIX kernel must empty out some locations in real memory for reuse of new pages.
This process is otherwise known as page replacement.

The AIX VMM has background daemons responsible for doing page replacement. A page replacement daemon is referred to as lrud (shows up as lrud in the output of ps -k).
lrud daemons are responsible for scanning in memory pages and evicting pages in order to empty locations in real memory. When a page
replacement daemon determines that it wants to evict a specific page, the page  replacement daemon does one of two things:




# If the page is modified, the page replacement daemon writes the page out to a secondary storage location.

# If the page is unmodified, the page replacement daemon can simply mark the physical memory block as free, and the physical memory block can
then be re-used for another page.

The page replacement daemons target different types of pages for eviction based on system memory usage and tunable parameters.

Fundamentally, there are two types of pages on AIX:

• Working storage pages (Computational pages)
• Permanent storage pages (Non-computational pages)

Working storage pages are pages that contain volatile data (in other words, data that is not preserved across a reboot).

* Process data
* Stack
* Shared memory
* Kernel data

When modified working storage pages need to be paged out (moved from memory to the disk), they are written to paging space. Working storage pages are never written to a file system.


When a process exits, the system releases all of its private working storage pages.

Permanent storage pages are pages that contain permanent data (that is, data that is preserved across a reboot). This permanent data is just file data. So, permanent storage pages are basically just pieces of files cached in memory.


When a modified permanent storage page needs to be paged out (moved from memory to disk), it is written to a file system.


As mentioned earlier, an unmodified permanent storage page can just be released without being written to the file
system, since the file system contains a pristine copy of the data.

You can divide permanent storage pages into two sub-types:

• Client pages
• Non-client pages

When you first open a file, the AIX kernel creates an internal VMM object to represent the file. It marks it as non-computational, meaning all files start out as non-computational.


As a program does reads and writes to the file, the AIX kernel caches the file's data in memory as non-computational permanent storage pages.


If the file is closed, the AIX kernel continues to cache the file data in memory (in permanent storage pages). The kernel continues to cache the file for performance;

for example, if another process comes along later and uses the same file, the file data is still in memory, and the AIX kernel does not have to read the file data in from disk.

AIX IO Tuning

AIX’s disk and adapter drivers each use a queue to handle IO, split into an in-service queue, and a wait queue.

Note that even though the disk is attached to the adapter, the hdisk driver code is utilized before the adapter driver code.

IO requests in the in-service queue are sent to the storage, and the queue slot is freed when the IO is complete.

IO requests in the wait queue stay there until an in-service queue slot is free, at which time they are moved to the in-service queue and sent to the storage.

IO requests in the in-service queue are also called in-flight from the perspective of the device driver.


The size of the hdisk driver in-service queue is specified by the queue_depth attribute, while the size of the adapter driver in-service queue is specified by the num_cmd_elems attribute.



root # lsattr -EHl fcs0
attribute value description user_settable
intr_priority 3 Interrupt priority False
lg_term_dma 0x800000 Long term DMA True
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 200 Maximum Number of COMMAND Elements True
sw_fc_class 2 FC Class for Fabric True

root # lsattr -EHl hdisk0
attribute value description user_settable
PCM PCM/friend/vscsi Path Control Module False
algorithm fail_over Algorithm True
hcheck_cmd test_unit_rdy Health Check Command True
hcheck_interval 60 Health Check Interval True
hcheck_mode enabled Health Check Mode True
max_transfer 0x40000 Maximum TRANSFER Size True
pvid 00c4c6c7b35f29770000000000000000 Physical volume identifier False
queue_depth 3 Queue DEPTH True
reserve_policy no_reserve Reserve Policy True

A physical disk can only do one IO at a time, but knowing several of the IO requests allows the disk to do
the IOs using an elevator algorithm to minimize actuator movement and latency.

Virtual disks typically are backed by many physical disks, so can do many IOs in parallel.

Maximum LUN IOPS = queue_depth/ (avg. IO service time)

Maximum adapter IOPS = num_cmd_elems/ (avg. IO service time)

Currently default queue sizes (num_cmd_elems) for FC adapters range from 200 to 500, with maximum  values of 2048 or 4096.

Rename A Device In AIX Using # rendev

# lspv
hdisk0          00f61ab2f73e46e2                    rootvg          active
hdisk1          00f61ab20bf28ac6                    None
hdisk2          00f61ab2202f7c0b                    None
hdisk4          00f61ab20b97190d                    None
hdisk3          00f61ab2202f93ab                    None

# rendev -l hdisk3 -n hdisk300

# lspv
hdisk0          00f61ab2f73e46e2                    rootvg          active
hdisk1          00f61ab20bf28ac6                    None
hdisk2          00f61ab2202f7c0b                    None
hdisk4          00f61ab20b97190d                    None
hdisk300        00f61ab2202f93ab                   None