Partition redispatching using page tracking

Illustrated embodiments provide a computer implemented method and data processing system for redispatching a partition by tracking a set of memory pages, belonging to the dispatched partition. In one illustrative embodiment the computer implemented method comprises finding an effective page address to real page address mapping for a page address miss in response to determining the page address miss in a page addressing buffer, and saving the mapping as an entry in an array. The computer implemented method creates a preserved array from the array in response to determining the dispatched partition to be an undispatched partition. The computer implemented method further analyzes of the preserved array for a compressed page in response to determining the undispatched partition is now redispatched, and decompresses the compressed page prior to the partition being redispatched.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to paging subsystems of a data processing system. More specifically, the present invention relates to a computer implemented method and data processing system for partition redispatching using page tracking.

2. Description of the Related Art

Increasingly, large symmetric multi-processor data processing systems are not being used as single large data processing systems. Instead, these types of data processing systems are being partitioned and used as smaller systems. These systems are also referred to as logical partitioned (LPAR) data processing systems. A logical partitioned functionality within a data processing system allows multiple copies of a single operating system, or multiple heterogeneous operating systems, to be simultaneously run on a single data processing system platform. A partition, within which an operating system image runs, may be assigned a non-overlapping subset of the platforms resources. These platform allocable resources include one or more architecturally distinct processors and respective interrupt management areas, regions of system memory, and input/output (I/O) adapter bus slots. The partition's resources are represented by the platform's firmware to the operating system image.

Each distinct operating system, or image of an operating system running within a platform, is protected from each other, such that software errors on one logical partition cannot affect the correct operation of any of the other partitions. This protection is provided by allocating a disjointed set of platform resources to be directly managed by each operating system image and by providing mechanisms for ensuring that the various images cannot control any resources that have not been allocated to that image. Furthermore, software errors in the control of an operating system's allocated resources are prevented from affecting the resources of any other image. Thus, each image of the operating system or each different operating system directly controls a distinct set of allocable resources within the platform.

With respect to hardware resources in a logical partitioned data processing system, these resources are shared disjointly among various partitions. These resources may include, for example, input/output (I/O) adapters, dual in-line memory modules (DIMMs), non-volatile random access memory (NVRAM), and hard disk drives. Each partition within a logical partitioned data processing system may be booted and shut down over and over without having to power-cycle the entire data processing system.

Most computers have a fixed memory and processor capacity. The virtualization of processors allows more operating system instances, or partitions, in a system than there are processors. This, in turn, tends to increase the memory required to run all of the partitions, as operating systems and applications have certain minimum memory requirements that do not tend to scale with processor power. This imbalance limits the effective number of partitions that a given system can support at any point in time.

Traditionally, virtual memory has been one solution to this problem. Virtual memory is a technique by which some of the memory used by a partition is actually on disk. Unfortunately, disk paging virtual memory schemes suffer greatly from the fact that microprocessor performance has increased at a much faster rate than disk performance. This gap reduces the effectiveness of disk based virtual memory to a huge degree. In fact, most UNIX™ customers tune their systems to avoid paging at all costs.

Virtual memory can be employed in a partition management firmware in an attempt to decrease the effective memory usage of partitions. However, disk-based virtual memory approaches in a partition management firmware will typically suffer the same issues as operating system based virtual memory. Another, similar approach is to apply compression algorithms to memory. This approach was used on certain International Business Machines Corporation “system X” products in the past. A hardware-based approach to memory compression is elegant as it is mostly transparent to software; however, it requires building special purpose hardware to deliver the function.

Software based compression seems poised as an alternative approach to hardware based compression. In a software based compression approach, the partition management firmware selects pages for compression and decompression. The actual compression and decompression function can be delivered either through processor based code or with accelerators. An accelerator is special purpose hardware that is optimized for specific algorithms, wherein the function may be located on the microprocessor chip itself, or outside the microprocessor chip. Software-based compression has the benefit of lower complexity and cost of hardware, in that it takes advantage of the massive increases in microprocessor performance.

For example, most systems have a considerable number of unused processor cycles that could be applied to compression and decompression. Further, benefits accrue because software based compression can be used selectively, and the latency to decompress a page in memory is lower than going to disk. Once systems are graced with compression and decompression accelerators, the partition management firmware can begin to use software compression aggressively. For example, when a partition is undispatched, the memory it was using can be compressed in the background by the partition management firmware until the partition is dispatched again.

SUMMARY OF THE INVENTION

Illustrated embodiments provide a computer implemented method, apparatus and computer program product for partition redispatching using page tracking. The computer implemented method comprises finding an effective page address to real page address mapping for a page address miss to create a found real page address and page size combination, responsive to determining the page address miss in a page addressing buffer, and saving the found real page address and page size combination as an entry in an array. The computer implemented method further comprises creating a preserved array from the array, responsive to determining the dispatched partition to be an undispatched partition. The computer implemented method further comprises analyzing each entry of the preserved array for a compressed page, responsive to determining the undispatched partition is now redispatched, and invoking a partition management firmware function to decompress the compressed page, prior to the partition being redispatched, responsive to determining a compressed page.

The data processing system comprising, a bus, a storage device connected to the bus; a memory connected to the bus, wherein the memory includes computer usable program code, and a processor connected to the bus, wherein the processor executes the computer usable program code to create a locator responsive to detecting a page address miss in a page addressing buffer, capable of finding an effective page address to real page address mapping for the page address miss to form a found real page address and page size combination. Further creating a storage module capable of saving the found real page address and page size combination as an entry in set of entries in an array, and updating the set of entries in the array to track page use and a generator capable of creating a preserved array from the array in response to determining the partition to be an undispatched partition. Further creating an analyzer capable of analyzing each entry of the preserved array for a compressed page responsive to determining that the undispatched partition is redispatched, and a partition management firmware function to decompress a compressed page, prior to the partition being redispatched, responsive to determining a compressed page referenced by one of the set of entries in the array.

The computer program product comprising computer usable program code tangibly embodied on a computer usable recordable type medium, the computer usable program code comprising computer usable program code for detecting a page address miss in a page addressing buffer, computer usable program code for finding an effective page address to real page address mapping for the page address miss to form a found real page address and page size combination and computer usable program code for saving the found real page address and page size combination as an entry in a set of entries in an array. The computer usable program code further comprising computer usable program code for updating the set of entries in the array to track page use and computer usable program code for creating a preserved array from the array in response to determining the partition is an undispatched partition. The computer usable program code further comprising computer usable program code for analyzing each entry of the preserved array for a compressed page responsive to determining that the undispatched partition is now redispatched, and computer usable program code for invoking a partition management firmware function to decompress a compressed page, prior to the partition being redispatched, responsive to determining a compressed page referenced by one of the set of entries in the array.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures, and in particular with reference toFIG. 1, a block diagram of an apparatus in the form of a data processing system in which illustrative embodiments may be implemented is depicted. Data processing system100may be a symmetric multiprocessor (SMP) system including processors101,102,103, and104, which connect to system bus106. For example, data processing system100may be an IBM® eserver™, a product of International Business Machines Corporation in Armonk, N.Y., implemented as a server within a network. Alternatively, a single processor system may be employed. Also connected to system bus106is memory controller/cache108, which provides an interface to local memories160,161,162, and163. I/O bridge110connects to system bus106and provides an interface to I/O bus112. Memory controller/cache108and I/O bridge110may be integrated as depicted.

Data processing system100is a logical partitioned (LPAR) data processing system. Thus, data processing system100may have multiple heterogeneous operating systems (or multiple instances of a single operating system) running simultaneously. Each of these multiple operating systems may have any number of software programs executing within it. Data processing system100is logically partitioned such that different PCI I/O adapters120,121,128,129, and136, graphics adapter148, and hard disk adapter149may be assigned to different logical partitions. In this case, graphics adapter148connects to a display device (not shown), while hard disk adapter149connects to and controls hard disk150.

Thus, for example, suppose data processing system100is divided into three logical partitions, P1, P2, and P3. Each of PCI I/O adapters120,121,128,129, and136, graphics adapter148, hard disk adapter149, each of host processors101,102,103, and104, and memory from local memories160,161,162, and163is assigned to each of the three partitions. In these examples, memories160,161,162, and163may take the form of dual in-line memory modules. Dual in-line memory modules are not normally assigned on a per dual in-line memory module basis to partitions. Instead, a partition will get a portion of the overall memory seen by the platform. For example, processor101, some portion of memory from local memories160,161,162, and163, and I/O adapters120,128, and129may be assigned to logical partition P1; processors102and103, some portion of memory from local memories160,161,162, and163, and PCI I/O adapters121and136may be assigned to partition P2; and processor104, some portion of memory from local memories160,161,162, and163, graphics adapter148and hard disk adapter149may be assigned to logical partition P3.

Each operating system executing within data processing system100is assigned to a different logical partition. Thus, each operating system executing within data processing system100may access only those I/O units that are within its logical partition. Thus, for example, one instance of the Advanced Interactive Executive (AIX) operating system may be executing within partition P1, a second instance (image) of the AIX operating system may be executing within partition P2, and a Linux or OS/400 operating system may be operating within logical partition P3.

Peripheral component interconnect (PCI) host bridge114connected to I/O bus112provides an interface to PCI local bus115. PCI I/O adapters120and121connect to PCI bus115through PCI-to-PCI bridge116, PCI bus118, PCI bus119, I/O slot170, and I/O slot171. PCI-to-PCI bridge116provides an interface to PCI bus118and PCI bus119. PCI I/O adapters120and121are placed into I/O slots170and171, respectively. Typical PCI bus implementations support between four and eight I/O adapters (i.e. expansion slots for add-in connectors). Each PCI I/O adapter120-121provides an interface between data processing system100and input/output devices such as, for example, other network computers, which are clients to data processing system100.

An additional PCI host bridge122provides an interface for an additional PCI bus123. PCI bus123connects to a plurality of PCI I/O adapters128and129. PCI I/O adapters128and129connect to PCI bus123through PCI-to-PCI bridge124, PCI bus126, PCI bus127, I/O slot172, and I/O slot173. PCI-to-PCI bridge124provides an interface to PCI bus126and PCI bus127. PCI I/O adapters128and129are placed into I/O slots172and173, respectively. In this manner, additional I/O devices, such as, for example, modems or network adapters may be supported through each of PCI I/O adapters128-129. Consequently, data processing system100allows connections to multiple network computers.

A memory mapped graphics adapter148is inserted into I/O slot174and connects to I/O bus112through PCI bus144, PCI-to-PCI bridge142, PCI bus141, and PCI host bridge140. Hard disk adapter149may be placed into I/O slot175, which connects to PCI bus145. In turn, this bus connects to PCI-to-PCI bridge142, which connects to PCI host bridge140by PCI bus141.

A PCI host bridge130provides an interface for PCI bus131to connect to I/O bus112. PCI I/O adapter136connects to I/O slot176, which connects to PCI-to-PCI bridge132by PCI bus133. PCI-to-PCI bridge132connects to PCI bus131. This PCI bus also connects PCI host bridge130to the service processor mailbox interface and ISA bus access pass-through194and PCI-to-PCI bridge132. Service processor mailbox interface and ISA bus access pass-through194forwards PCI accesses destined to the PCI/ISA bridge193. NVRAM storage192connects to the ISA bus196. Service processor135connects to service processor mailbox interface and ISA bus access pass-through logic194through its local PCI bus195. Service processor135also connects to processors101,102,103, and104via a plurality of JTAG/I2C busses134. JTAG/I2C busses134are a combination of JTAG/scan busses (see IEEE 1149.1) and Phillips I2C busses. However, alternatively, JTAG/I2C busses134may be replaced by only Phillips I2C busses or only JTAG/scan busses. All SP-ATTN signals of the host processors101,102,103, and104connect together to an interrupt input signal of service processor135. Service processor135has its own local memory191and has access to the hardware OP-panel190.

When data processing system100is initially powered up, service processor135uses the JTAG/I2C busses134to interrogate the system (host) processors101,102,103, and104, memory controller/cache108, and I/O bridge110. At the completion of this step, service processor135has an inventory and topology understanding of data processing system100. Service processor135also executes Built-In-Self-Tests (BISTs), Basic Assurance Tests (BATs), and memory tests on all elements found by interrogating the host processors101,102,103, and104, memory controller/cache108, and I/O bridge110. Any error information for failures detected during the BISTs, BATs, and memory tests are gathered and reported by service processor135.

If a meaningful and valid configuration of system resources is still possible after taking out the elements found to be faulty during the BISTs, BATs, and memory tests, then data processing system100is allowed to proceed to load executable code into local (host) memories160,161,162, and163. Service processor135then releases host processors101,102,103, and104for execution of the code loaded into local memory160,161,162, and163. While host processors101,102,103, and104are executing code from respective operating systems within data processing system100, service processor135enters a mode of monitoring and reporting errors. The type of items monitored by service processor135include, for example, the cooling fan speed and operation, thermal sensors, power supply regulators, and recoverable and non-recoverable errors reported by processors101,102,103, and104, local memories160,161,162, and163, and I/O bridge110.

Service processor135saves and reports error information related to all the monitored items in data processing system100. Service processor135also takes action based on the type of errors and defined thresholds. For example, service processor135may take note of excessive recoverable errors on a processor's cache memory and decide that this is predictive of a hard failure. Based on this determination, service processor135may mark that resource for de-configuration during the current running session and future Initial Program Loads (IPLs). IPLs are also sometimes referred to as a “boot” or “bootstrap”.

Data processing system100may be implemented using various commercially available computer systems. For example, data processing system100may be implemented using IBM eServer iSeries™ Model 840 system available from International Business Machines Corporation. Such a system may support logical partitioning using an OS/400™ operating system, which is also available from International Business Machines Corporation.

With reference now toFIG. 2, a block diagram of an exemplary logical partitioned platform is depicted in which illustrative embodiments may be implemented. The hardware in logical partitioned platform200may be implemented as, for example, data processing system100inFIG. 1. Logical partitioned platform200includes partitioned hardware230, operating systems202,204,206,208, and partition management firmware210. Operating systems202,204,206, and208may be multiple copies of a single operating system or multiple heterogeneous operating systems simultaneously run on logical partitioned platform200.

These operating systems may be implemented using OS/400, which are designed to interface with a partition management firmware, such as partition management firmware, which is available from International Business Machines Corporation. OS/400 is used only as an example in these illustrative embodiments. Of course, other types of operating systems, such as AIX™ and Linux™, may be used depending on the particular implementation. Operating systems202,204,206, and208are located in partitions203,205,207, and209.

Partition management firmware software is an example of software that may be used to implement partition management firmware210and is available from International Business Machines Corporation. Firmware is “software” stored in a memory chip that holds its content without electrical power, such as, for example, read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), and nonvolatile random access memory (nonvolatile RAM).

Additionally, these partitions also include partition firmware211,213,215, and217. Partition firmware211,213,215, and217may be implemented using initial boot strap code, IEEE-1275 Standard Open Firmware, and runtime abstraction software, which is available from International Business Machines Corporation. When partitions203,205,207, and209are instantiated, a copy of boot strap code is loaded onto partitions203,205,207, and209by platform firmware210. Thereafter, control is transferred to the boot strap code with the boot strap code then loading the open firmware and runtime abstraction software. The processors associated or assigned to the partitions are then dispatched to the partition's memory to execute the partition firmware.

Partitioned hardware230includes processors232,234,236, and238, memories240,242,244, and246, input/output (I/O) adapters248,250,252,254,256,258,260, and262, and a storage unit270. Each of processors232,234,236, and238, memories240,242,244, and246, NVRAM storage298, and I/O adapters248,250,252,254,256,258,260, and262may be assigned to one of multiple partitions within logical partitioned platform200, each of which corresponds to one of operating systems202,204,206, and208.

Partition management firmware210performs a number of functions and services for partitions203,205,207, and209to create and enforce the partitioning of logical partitioned platform200. Partition management firmware210is a firmware implemented virtual machine identical to the underlying hardware. Thus, partition management firmware210allows the simultaneous execution of independent OS images202,204,206, and208by virtualizing all the hardware resources of logical partitioned platform200.

Service processor290may be used to provide various services, such as processing of platform errors in the partitions. These services also may act as a service agent to report errors back to a vendor, such as International Business Machines Corporation. Operations of the different partitions may be controlled through a hardware management console, such as hardware management console280. Hardware management console280is a separate data processing system from which a system administrator may perform various functions including reallocation of resources to different partitions.

Illustrative embodiments provide a capability to reduce the delay encountered by a partition when a previously accessed, recently used, page of memory has to be decompressed during the redispatch process. For example, with reference to partition203and partition management firmware210of logical partitioned platform200ofFIG. 2, if partition203was executing but then had to wait for an input/output service to complete, partition management firmware210would have stopped partition203, and changed the dispatch status to undispatched. After the input/output operation completed, partition management firmware210would mark partition203ready for execution again and eligible to be redispatched. During the redispatch process, resources needed by partition203would be made available by partition management firmware210. Partition management firmware210would analyze the page memory requirements to dispatch partition203. A subset of pages of memory, specifically those pages previously accessed, and recently used, by partition203would be decompressed prior to the redispatch to avoid a “stall” while partition203was being redispatched.

Illustrative embodiments provide a tracking mechanism to be used by partition management firmware in the form of an array, in a storage module or area such as memory240-246or NVRAM298; containing real page addresses of the most recently used (MRU) pages for the microprocessor. Before the respective partition is to be redispatched, the partition management firmware begins to decompress the previously accessed pages recorded as most recently used by the partition. The decompress function can occur before the partition is dispatched, in order to reduce stalls due to decompression, thereby reducing the time needed to have the partition up and running. Alternatively, decompression may continue concurrently with the dispatch of the virtual processor. Concurrent decompression can be particularly useful in highly threaded designs, where some hardware threads are typically idle.

With reference toFIG. 3a block diagram comprising a subset of partition management components ofFIG. 2is shown. Partition management firmware210performs a number of functions and services for partition203by utilizing a variety of components including those of virtual processor302, ready-to-run queue304, dispatch queue306, dispatch mechanism308and array310in accordance with illustrative embodiments.

Virtual processor302comprises the logical definitions for the processors that have been virtualized by partition management firmware210. Ready-to-run queue304contains the list of tasks that are in line to be processed and ready. Dispatch queue306contains the list of tasks that are about to run as soon as dispatch mechanism308allows. Dispatch mechanism308contains functions that determine which tasks are dispatched into execution. Tasks to be dispatched are selected from the ready-to-run queue304by dispatch mechanism306, analyzed and selectively placed on dispatch queue308.

Partition management firmware210may be implemented through use of software. The software of the partition management firmware then works in combination with the hardware to provide and manage the environment ofFIGS. 1 and 2. While partition203runs, pages of real memory, for example memory240ofFIG. 2, may be allocated and used by partition203in the performance of its tasks. As partition203utilizes this memory, the hardware and the partition management firmware resolve the effective addresses of the pages of partition203with those of the real addresses of partitioned hardware230. This page mapping is an integral function of the hardware and the partition management firmware.

Modern microprocessors employ high speed caches forming a page addressing buffer, such as translation look-a-side buffers (TLBs), as may be found in memory controller/cache108ofFIG. 1, to provide effective page address to real page address translation. These high speed caches are highly optimized for system performance.

As addresses are translated in a translation look-a-side buffer, the addresses either hit in the translation look-a-side buffer or miss. If there is a miss, the addresses are resolved to a new effective page address to real page address mapping in hardware if the mapping exists. If the mapping does not exist, the partition management firmware210or the operating system of the partition may allocate a page mapping to resolve the translation miss. The real page address for each miss will be placed into an additional array, such as array310. If the microprocessor supports multiple page sizes, the page size is also entered into the array310with the real address. As each new real page address is placed into the array310, an old page address is displaced. This gives the array310the property of holding the most recently used (MRU) pages for the microprocessor.

When partition203that was dispatched and executing, becomes undispatched, due to an interrupt or waiting for another process such as input/output device delay, the partition management firmware210saves the values of the array310in a memory location specific to that virtual processor's state. The partition management firmware210should not record any addresses into the memory containing the array310that does not belong to the respective partition in which the particular virtual processor executes. This could be accomplished by either not recording addresses when running in partition management firmware state, by having the partition management firmware run in real address mode, thereby not using address translation mechanisms, or by reserving the memory for the specific purpose of page address tracking for the specific partition.

If the partition is no longer waiting on a resource it may then be placed in the ready to run queue304. Dispatch mechanism308will then analyze and place on the dispatch queue306if the partition is ready for dispatch. Before the partition is to be redispatched to execute again, the partition management firmware begins to decompress the previously accessed pages recorded in array310as most recently used by the partition. The decompress function can occur before the partition203is dispatched, in order to reduce stalls due to decompression. Reduced stalls reduce the time needed to have the partition up and running. Alternatively, decompression may continue concurrently with the dispatch of the virtual processor. Concurrent decompression can be particularly useful in highly threaded designs, where some hardware threads are typically idle.

Turning toFIG. 4, a flowchart of an exemplary process of page tracking is shown in accordance with illustrative embodiments. Process400is implemented within and extends the current page address translation process of the partition management firmware software210ofFIG. 2. Process400may be further viewed as a combination of information found in array310, ofFIG. 3, for page tracking, with the memory page processing of partition management firmware210. The partition management firmware210provides a paging subsystem service to each of the defined partitions of logical partitioned platform200ofFIG. 2.

Partition management firmware210functions in support of the logical partitions. An existing locator within the paging subsystem service capable of finding the effective page address to real page address mapping for a page address miss when it has been determined that there is a page address miss in a page addressing buffer contained within the memory is also used.

A storage module or area, such as memory240-246ofFIG. 2, is used to store array310, capable of saving the real page address and a page size combination as an entry in an array within the memory is also provided. The storage module or area may typically be managed by an existing storage device capable of writing data into a buffer or other suitable storage location defined for the task. The storage module or area should have performance characteristics suitable for maintaining the page addressing data with an affinity to the virtual processor or partition to which the data belongs as well as low latency for read and write time. Disk storage may provide the storage function, but may not meet the latency criteria; therefore, use of a high speed memory form is advisable.

A generator capable of creating a preserved array from the array310upon determining the dispatched virtual processor or partition to be an undispatched virtual processor or partition is typically a function of partition management firmware210, capable of persisting data. Functions of partition management firmware210typically include capabilities to write data into a reserved area of a partition or firmware in the form of a control block or other well known controlled access storage.

An analyzer, such as that of the paging subsystem service of partition management firmware210, is capable of analyzing each entry of the preserved array to find a compressed page, wherein, dispatch mechanism308ofFIG. 3has determined the undispatched partition ready for dispatching. Analysis may typically comprise a flag checking function used to determine if a flag indicating a compressed page is set, or a pattern recognition mechanism aware of the format of the compressed pages, or other means unique to the compression format of the compressed pages.

Partition management firmware210ofFIG. 2provides function executed on the processor to decompress a compressed page into the memory such as memory240and map it to a virtual address used by for example OS202, thus making the decompressed page ready for use by the partition203. The partition management firmware210typically provides function to detect a compressed page and may be used with page size information of the preserved array to decompress pages.

Process400, of partition management firmware210, starts during memory page address translation, wherein a determination is made with respect to a page address translation existing in the translation look-a-side buffers (step402). If there is a page address hit then a “yes” in step402, indicating there is no miss in the translation of the page address and process400returns to normal page address translation processing. If however, there is a “no” in step402, then a translation look-a-side buffer miss has occurred meaning the effective page address to real page address mapping was not found. Process400moves to step404to find the required mapping.

In this case, the desired page address mapping was not found in translation look-a-side buffers; therefore, the required effective real page mapping must be found (step404). The real page address, along with the respective page size, is then saved into the array. When performing a save into the array, the oldest real page address and page size combination is replaced with the newest real page address and page size combination (step406).

The array is a high speed memory location reserved to contain the most recently used page address and page size combinations of a respective partition. The array functions as a page tracking mechanism of the partition's most recently used page addresses. Memory, such as memory240ofFIG. 2or NVRAM298of logical partitioned platform200ofFIG. 2or another form of accessible high speed memory may be used to accommodate the array of illustrated embodiments. NRAM298ofFIG. 2may be used to maintain paging information across power outages. Sizing of the array may be typically accomplished by observing partition activity and paging statistics.

A determination is made with respect to the dispatch status of the partition (step408). When the partition is undispatched (“yes” to step408), process400saves the array representing the most recently used addresses in a context area of the respective partition to create a preserved array (step410). If, however, the partition is dispatched, (“no” to step408), then process400reverts to normal memory page address translation as prior to step402.

A determination is made with respect to the dispatch readiness of the partition (step412). If the partition is not ready for dispatch “no” in step412), process400will revert to perform step412again. If the partition is ready to be dispatched (“yes” to step412), and before the partition is dispatched, for each page address and page size combination in the preserved array, a determination is made if the page is compressed (step414).

If the page has been compressed, (“yes” to step414), the page can be decompressed prior to use (step416). If the page was not compressed and is ready to be used, (“no” to step414), process400skips step416and moves to step418wherein a determination is made regarding the existence of more pages to be processed. If there are more pages to be processed (“yes” to step418), process400reverts to step414to examine each page for its compress status. If there are no additional pages to be processed, (“no” to step418), process400moves to determine if the partition is dispatched (step420).

If the partition has not been dispatched, (“no” to step420) process400will iterate in step420. If the partition is dispatched, (“yes” to step420), process400clears the entries of the preserved array (step422). The most recently used entries of the array are cleared to avoid carrying state information from a previously running instance of the partition. Having cleared the array, process400reverts to normal page address translation processing as before at step402.

Differing illustrative embodiments provide a number of features. Since only a subset of the pages used by the partition, in particular those most recently used and compressed, are decompressed; other compressed pages belonging to the partition will have to be decompressed after dispatching of the partition. During the normal course of execution, access of a compressed page results in a partition management firmware page fault. The page fault causes the partition management firmware to perform page decompression as part of the typical partition management service, which may be desired in a multithreaded well resourced situation.

The page tracking array typically aids in a more efficient restart of a previously suspended partition by indicating the most recently used pages, some of which may be compressed. Avoiding or reducing initial stalls due to page faults related to encountering a compressed page during the redispatch of the previously undispatched partition is achieved through use of the page tracking array information. The early identification and handling of the most recently used pages of the array compliments the partition management firmware virtual memory management function. By knowing which pages are needed initially to bring the partition back into operation, and knowing which of those pages are compressed allows the partition management firmware to more effectively

Further, a computer storage medium may contain or store a computer readable program code such that when the computer readable program code is executed on a computer, the execution of this computer readable program code causes the computer to transmit another computer readable program code over a communications link. This communications link may use a transmission medium that is, for example without limitation, physical or wireless.