Dynamic Reconfiguration User's Guide 2.5.1

2.1.3.3 DR Detach

Handling of detaching memory differs from one another if the hardware supports the removal of kernel memory.

[ PRIMEPOWER 900/1500/2500 ]

PRIMEPOWER 900/1500/2500 support the removal of kernel memory. In order to delete kernel memory on the board, the system has to copy the kernel data to another board and needs to suspend until the copy is finished. Due to this process, detaching the kernel memory board takes some time.

When detaching the kernel memory board, the system copies the kernel data to other board fulfilling the conditions.

• The board has enough memory (greater or equal to size) to copy the data.
• The board has the same memory configuration or the configuration encompassing the kernel memory board configuration.
• The board doesn't contain kernel memory.
• The board is not specified by no-obp-sb-cX or no-obp-sb. (See section 2.3.2.1 "Kernel memory allocation option")

When the system can't detect any boards fulfilling the conditions, detaching the kernel memory board fails. For example, if other boards have less memory than the kernel memory board, or other boards have different memory configuration, detaching the kernel memory can fail. It's recommended that each board has the same memory size including the memory configuration to prevent the failure.

Note that the last condition above is not always required; when drc command is invoked, and there is no other system boards meeting the conditions than the board specified by no-obp-sb-cX or no-obp-sb, the inquiring messages prompt you for what to do with the board specified by no-obp-sb-cX or no-obp-sb. By replying "Yes", the process can continue, and the board is chosen to copy kernel memory. (See section 3.1 "drc(1M)", section 2.3.2.1 "Kernel memory allocation option", section 6.1.3.3 "Inquiring Messages" and section 7.1.3.3 "Inquiring Messages" in detail)

[ GP7000F model 1000/2000 and PRIMEPOWER 800/1000/2000 ]

Solaris OS supports a kernel cage memory feature, which confines kernel memory usage to a minimum subset of system boards. To make the best use of this feature, it is recommended that the system administrator reserves the system board with the largest memory size for the boot board, which is used first at boot time.

To detach the user memory board (kernel is not resident in the memory), all user memory and file system data must be flushed out to the backing storage devices. Although this process can take a while, it is done in the background and the system can still service all the user applications.

Locked/ISM (Initiated Shared Memory) memory pages fall in between non-kernel page and kernel page. They do not contain critical kernel data but they must be migrated to other memory boards instead of being flushed out to the backing storage. The detach process can fail if the system cannot find enough space elsewhere to migrate these pages.

In summary, DR user memory detach will fail if:

• The system board contains kernel page.
• There is not sufficient swap space to flush all non-kernel pages.
• There are too many locked/ISM pages to migrate them elsewhere.

In the connection script, the DR service command dr_info can be used to query the system to find out if there is any kernel page on a particular system board. Or drcstat -system shows if a specified system board contains kernel memory. Please read the section 3.2 "drcstat(1M)" or section 3.5.3 "dr_info" for more information. The system minimizes the number of system boards where kernel memory resides. Please read "2.3.1 How to enable DR and Kernel cage memory" for details.