Browse Prior Art Database

Method and Apparatus for Storage Reconfiguration Disclosure Number: IPCOM000035224D
Original Publication Date: 2005-Jan-20
Included in the Prior Art Database: 2005-Jan-20
Document File: 2 page(s) / 44K

Publishing Venue



A method and apparatus for storage reconfiguration is described.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Method and Apparatus for Storage Reconfiguration

The current storage reconfiguration algorithm in *z/OS configures real storage to be on-line and usable to the system or off-line. Two software components are involved with storage reconfiguration: a Real Storage Manager (RSM) and a Reconfiguration component. The RSM has control over the allocation of the on-line storage and the Reconfiguration component has control over which real storage increments are chosen for an off-line or on-line request. There are three distinct components of this invention.

1. Page Shuffle Avoidance. Currently, the RSM is called by Reconfiguration on a sub-increment basis of the total memory to configure. The Reconfiguration component does not make available to the RSM component any future sub-increment that is currently selected for the off-line request. The RSM moves any pages backed by the sub-increment that is going off-line to another currently on-line sub-increment without regard to whether the target sub-increment is going off-line in the same request. A virtual page may end up moving from one sub-increment to another to another for a single off-line request. This algorithm has the potential to have major performance implication as real storage configured on a system continually grows and the potential size of a storage request becomes larger. This action can cause "thrashing" and high overhead during a reconfiguration process, especially if an address space must be swapped out to free a frame in the sub-increment that is being processed. Instead of calling the RSM once for each sub-increment, Reconfiguration will call the RSM in two stages: A "Status and Prepare" stage and a "Do It" stage. A single threaded queue of control blocks will be created to maintain the status of the sub-increment over the duration of the two stages. In the "Status and Prepare" step the Reconfiguration component will call the RSM to get the status of all sub-increments in the system. The Reconfiguration component will then sort the storage increments such that the most viable candidates can be chosen first for the reconfiguration request. The Reconfiguration component will sort the increments according to how many on-line sub-increments are in each increment and also by whether each increment is a reconfigurable or not reconfigurable. The first increments selected will be the ones that are reconfigurable and have...