JPH05210524A - Method of controlling storage device, computer system and product for usage in computer system - Google Patents

Abstract

PURPOSE: To manage the page of a virtual storage device of computer system in a reserved page release state by delaying the release of an actual page by a system after the release is demanded by the guest program of the system. CONSTITUTION: In a VM/ESA system 10, when reserved page release is set, entry is generated in the log of the reserved page release, and a page to be assigned to a guest is left. In the system 10, the page in the log can be release any time, and the execution of batch page release can be attained. The guest can demand the cancellation of the reserved page release, and at that time, the demanded page is removed from the log for reuse by the guest when the demanded page is not demanded by the system. The system processes the log of the reserved page release demand for conventionally operating the release of the reserved page.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION This invention relates to digital computer systems and, more particularly, to virtual storage management implemented by operating system software.

[0002]

BACKGROUND OF THE INVENTION Today, many digital computer systems use virtual storage devices, which are generally subdivided into elements called fixed size (eg, 4,096 bytes) pages. The contents of the virtual page must reside in main memory to allow access by the central processing unit (CPU).

System Storage Manager (SSM)
Is a component of the system that is responsible for advancing the contents of virtual memory into main memory and providing and clearing main memory frames when a new (empty) page is to be matched. In a system with multiple storage device types, the SSM manages the migration of virtual page content through its storage hierarchy, which may include additional electronic storage devices (eg, extended storage devices) or , Secondary storage (eg, disk storage, also known as DASD). This migration is required because the overall capacity of virtual storage on the system is usually much larger than the capacity of main storage. In fact, it is common that only the last (lowest speed) level of the storage hierarchy is large enough to contain all of the virtual memory.

In a computer system with virtual memory, the contents of a virtual page are needed when the contents of a virtual page represent data or logic that is necessary for the previous transaction, but not related to the next transaction. Often unsuitable for use. If the SSM is not aware that the content of the page is unusable, the SSM either saves the page in main memory or moves the page to another level of the storage hierarchy. You have to save the contents. In a system with a multi-level storage hierarchy, the content may be moved to a slower level while the page is idle. On the other hand, if the SSM senses that the content is unusable, the SSM can release the storage without saving the content, thereby avoiding migration.

Many prior art systems have no way to identify pages that are not suitable for use. By this disregard, SS
If M continues to migrate unusable data through different levels of the storage hierarchy, it will result in unnecessary churning in some of the SSMs. Further, pages are resources (eg, main storage, extended storage) whatever the level (s) of the hierarchy in which they reside, whatever the level.
Keep picking up.

To address these issues, some prior art systems have implemented a page release function to identify unsuitable pages to the SSM. The components of this system operate in a virtual storage environment and are able to identify unusable pages to the SSM. This component is typically part of the user program and is the User Storage Manager (UMM).
Is called. This UMM identifies the unsuitable page to the SSM, which immediately reuses the next associated storage resource.

The known prior art page release system has the following drawbacks.

1. All pages must be released at the time of the request, even though the system has more memory than is sufficient at the time of the original release request. SSM cannot defer its release until there is an increase in system requirements for storage, as the owner may begin reusing pages in the meantime.

2. The main memory page is the translation index buffer (T
IBM Enterprise Systems using LB)
When released in systems such as Architecture / 370 (ESA / 370) (trademark of IBM Corporation), each TLB entry must be invalidated before returning control to the user. The SSM may only purge individual entries for pages where the entire TLB or main memory has been released. Purging the entire TLB has the disadvantage of requiring a complete conversion at the first time each page is subsequently matched. Purging individual entries requires the use of an invalid page table entry (IPTE) instruction that waits for communication to and response from each CPU in the configuration. In the case of a 6-way system, this results in the instruction issuing CPU executing the instruction for a very long time (average instruction up to 200 times), similar to interference in other CPUs.
Further details regarding this translation lookaside buffer (TLB) can also be found in the principles of IBM Enterprise Systems Architecture / 370 operation.

3. It can only be executed for those pages identified for the current request. For this reason, batching of multiple page release requests is not possible. Address space location and serialization and required housekeeping must be performed with each page release.

[0011]

SUMMARY OF THE INVENTION It is an object of the present invention to batch release a computer virtual storage management system having a plurality of storages, such as pages, at least one of which is allocated to a user of the system such as an application program or a guest operating system. Is to provide.

[0012]

One embodiment of the present invention is a computer virtual storage device management system having a plurality of storage devices, such as pages, at least one of which is assigned to a user of the system such as an application program or a guest operating system. It is a method to provide batch (collective) release. By using this method with a page of virtual memory, the user can request the release of the first page, thereby identifying the page to the system as unusable and ready for release. Become. The system then grants the request and places the first page in the pending release state, while deferring the actual release of the page. The user requests the page again, this time the second page, the release, and the system grants the request,
Place the second page in the pending release state. Finally,
The system decides to release pages that are in pending release state and continues to release those pages in batches.

Another embodiment of the present invention is shown in a computer system that includes multiple storage devices (such as pages) that can be allocated to users of the system.
The first program module, which is preferably part of the storage manager in the host operating system, includes a first module that sequentially places the first and subsequent storage devices assigned to the user in a pending release state. The system also includes a second module for actually releasing the storage device in the pending release state.

Yet another embodiment of the present invention relates to an article of manufacture, preferably a prerecorded computer program product. The manufactured article includes a recording medium such as a magnetic tape for recording a computer program executable by a computer system. A computer system will have multiple storage devices (such as pages) that can be assigned to and released by users. Two program modules embodying the invention are recorded on the medium and are executable on the system. The first module continuously places the storage device in the pending release state at the request of the user. The second module releases the storage device in the pending release state.

Pseudocode fragments are shown in the figures to represent program modules for implementing the preferred embodiment of the present invention. Pseudocode provides the easiest and most universal way to explain the design and operation of program modules to a reader skilled in the art. This pseudo code is directly interpreted,
Or it cannot be compiled, but it will of course be understood that it needs to be translated into the reader's preferred programming language.

[0016]

DETAILED DESCRIPTION Preface The batch page release (BPR) operation of the present invention provides the system with a means for a user to continuously identify one or more groups of non-usable pages for placement in a pending release state. To do. The system does not postpone releasing pages in pending release state, and instead of forcing the system to release them immediately, it does so at a time when the system indicates that a release is needed by the system. To release.

While batch page release (BPR) can be applied to all prior art page release systems, it is embodied in combination with the pending page release invention described and claimed in the related US patent application entitled Pending Page Release. Preferably.

Background of the Implementation While applicable to other virtual storage environments, a detailed description of the preferred embodiment of the present invention is set up in a virtual machine / extended system architecture (VM / ESA) environment. As shown in FIG. 1, the VM / ESA system 10 includes VM / ESA software and real (ie, physical).
Includes system 370 / ESA machine 12. VM / ES
The A software further includes a VM / ESA control program (CP) 14 and a VM / ESA interactive monitoring system (CM).
S) 16. The CP 14 manages the hardware configuration using shared, split, simulated and dedicated techniques to create and maintain a virtual machine 18 that is functionally equivalent to the real hardware complex.
The CMS 16 operates in a virtual machine and provides a platform for conversational computing.

A user (program) running on the VM / ESA virtual machine 18 is called a guest, while a control program (CP) 14 running on the real machine 12 is called a host, which functions as the system of the present invention. Run. To call the guest program, the CP uses a hardware function called interactive execution. This allows guest instructions to be executed in a special environment that takes into account the virtual machine architecture and protects the real machine from the guest. The actual instruction used to enter the interactive execution mode and call the guest program is Start Interactive Execution (SIE).

The User Storage Manager (UMM) for the CMS 16 is the CMS Storage Manager (CM
SSM) 20. Programs running in the CMS virtual machine get the storage they need for (control blocks, work areas, program loading, etc.) via requests to the CMSSM. If these programs require no more storage, they return it to CMSSM.

The system storage manager (SSM) in the VM / ESA system 10 is a real storage management component (CPR) of the VM / ESA control program (CP) 14.
SM) 22 and various machine aids and functions, including dynamic address translation, which operate on 4 kilobyte pages on 4 kilobyte boundaries.

In VM / ESA system 10, guests can request services and / or information from CP 14 via DIAGNOSE commands.
Its usage is similar to the usage of supervisor calls in other SYSTEM / 370 systems. DIAGN by guest
The result of the execution of an OSE (diagnostic) instruction is what is known as an instruction block. This shut down causes the machine to store information identifying the shut down instruction (DIAGNOSE in this case), then exit the interpretive execution mode and return to the host control program (CP) 14.

Pending Page Release Instruction Batch page release (BPR) begins with a guest request to release a first page or range of pages.
This request may be a conventional page release request, but is preferably a request to set a pending page release (PPR).

To set the PPR, the CMSSM20
Issues a DIAGNOSE instruction 24 with a function code X'214 'that identifies the request as being PPR related. FIG. 2 shows the DI of the VM / ESA system 10.
The instruction format and register contents for the PPR function of the AGNOSE instruction are shown.

The DIAGNOSE instruction is 31 bits long, and first has a hexadecimal opcode X'83 '(reference numeral 2
It has 8 bits (0-7) including 6), which identifies the instruction as DIAGNOSE. Next 4
Bits (8-11) specify the even-even register pair RX (reference numeral 28) and RX + 1 (reference numeral 34) containing the start and end page addresses for the page affected by the instruction. Subsequent 4 bits (12
-15) specifies a register RY (reference number 30) containing a key value for use during a PPR cancel operation (described below). The last 16 bits (16-31) are the hexadecimal value X'214 'to specify that this DIAGNOSE instruction is for a pending page release.
It is a function code 32 including the.

Registers RX (28) and RX + 1 (3
Each bit 1-19 of 4) forms a 31-bit address of the virtual storage page with 12 bits of zeroes attached to the right of each. Even register RX (2
8) specifies the address 36 of the first page in the range, ie the starting address of the range of pages affected by the PPR instruction. Odd number register RX + 1 (34) is at address 3 of the end of the range of affected pages, ie, the end.
Specify 8. This "range" may be a single page, in which case bits 1-1 of RX and RX + 1.
9 is the same.

Bit 2 of odd number register RX + 1 (34)
8 to 31 designate the sub-function code 40 of the PPR instruction. This sub-function code allows the guest to specify whether a pending page release should be set or canceled as described below. Option request field (ORF) consisting of bits 24-27 of odd register RX + 1
42 is used to specify an optional service to be performed if the PPR is canceled.
When PPR is set, the ORF 42 is ignored because no optional service is provided.

The PPR log 44 contains a CPRSM for each guest that has one or more pages in pending release status.
Maintained by 22. If CPRSM receives a request to set a pending page release and the guest does not currently have a log, then a log is generated. The log contains pointers used to locate the next available entry. That same pointer locates the last valid entry in the log. An example of the PPR log is shown in FIG.

Set Pending Page Release CMSSM 20 allocates storage to the application program for each partition that is small, large or equal in size to the page, and thus partitions of different sizes are returned to CMSSM. The CMSSM merges the returned storage with its other unallocated storage. When one or more pages are no longer allocated as a result of this process, the CMSSM requests a Pending Page Release (PPR) for those pages and the CPR
The SM will add an entry to its PPR log, which will put the unusable page in the pending release state. When two or more PPRs are set, the system can also perform batch page release (BPR) by processing the logs as described below.

CMSSM registers PPR subfunction code 40 set to zero and registers RX (28) and RX + 1 (34) which specify the range of pages to be released.
PAG / DIAGNOSE for pages not suitable for use
Set the PPR by issuing instruction 24 to CPRSM 22.

When the CPRSM 22 receives the DIAGNOSE command 24 requesting the setting of the pending release, the CPRSM 22
The SM only makes an entry in the log 44 by storing the starting and ending page addresses (contained in registers RX (28) and RX + 1 (34)) in the next available log entry. If there is no space in the log, C
PRSM processes the log as described below and makes a new entry. If the current request identifies a range of pages that is adjacent to a range already in the log, the previous entry will be modified to include a new contiguous page by changing the starting or ending page number.

In addition to making log entries, C
The PRSM 22 reuses any extended storage and DASD used to hold the contents of the released page. In the VM / ESA system 10, these resources are not reused for released pages, so it makes sense to reuse them when setting the release. In other systems where such resources can be reused, deferring their reuse may be more effective.

3 and 4 include a pseudo code fragment for setting a pending page release. Line 1
In 01 to 105, the CMSSM is executed before the PPR instruction is executed.
20 are described, while the lines 106-115 describe the operation of the CPRSM 22 after execution and shutdown of the PPR instruction.

First (line 101), CMSSM20
Merges the returned partitions to form a complete page of unallocated storage. Next (line 102-1
03), the CMSSM uses D to identify the page range.
Odd-even register pair R to be used in IAGNOSE instruction 24
Set up X (28) and RX + 1 (34).
Further (line 104), the sub-function code 40 is PP
Set to zero to identify the request as an R set operation. Finally (line 105), the CMSSM executes the PPR DIAGNOSE instruction 24 to perform the requested PPR operation using register pair 28,34.
As a result of the execution of the PPR / DIAGNOSE instruction 24, the interpretation execution mode is left through the instruction cutoff and control is sent to the CP 14.

Following the command block, the CP router 46 determines if the block is due to a DIAGNOSE 214PPR command (line 106), and if so, P.
The PR sub-function code 40 is checked. If the PPR sub-function code is zero (line 107) and the instruction is P
If the request is a PR setting request, CPRSM22
Will continue to check if CMSSM 20 has an available PPR log 44 and generate it if required (line 108). If the CMSSM PPR log is full (line 109), it is processed as described below with respect to FIG.

If the identified pages are associated with existing entries, they are added to that entry (line 110). Otherwise, the next available slot 48a, 48b, 48c, ... In the log is located (line 111) and the located slot is populated with the contents of the odd-even register pair RX (28) and RX + 1 (34). A log entry is created by storing (line 1
12). DASD slots and extended storage blocks are reused for each page in the range (lines 113-115). Store-resident pages remain valid in storage where they can be referenced by the CPU. Finally, the CMSSM 20 is recalled by executing a Start Interpretation Execution (SIE) instruction (line 11).
6).

To further summarize, when the CMSSM 20 becomes perceived as an unsuitable page, the CMSSM 20
CPRSM22 via R ・ DIAGNOSE command 24
Send a signal to. The parameters of the DIAGNOSE command are
An odd-even register pair 28, 34 is identified which contains the starting address of the page range, the ending address of the page range, and a sub-function code indicating that each page in the range should be placed in the pending release state. DIAGNOSES causes a command block, allowing the CPRSM 14 to process PPR requests. Full PPR during PPR setting
The log 44 is processed (described below) and a missing log is created if necessary. Next available slot 48 in PPR log
a, 48b, 48c, ... Are filled with the contents of the odd-even register to generate a PPR log entry. DAS
The D and extended storage resources are reused and the CMSSM
Is recalled. The PPR setting operation is thus done without the system actually causing the page to be released.
"Hold release" page or range of pages from guest
Put in the state.

Pending Release Log Processing Pages that are pending releases are released by the system in batch page released (BPR) state, or
Or returned to the guest for reuse by a PPR cancel operation as described below. The batch release of the pages in the pending release status is performed by the guest PPR log 44.
Is executed by processing.

In the VM / ESA system 10, the guest PPR log 44 is processed by the CPRSM 22.
This is done when the guest goes inactive (dormant) or some of the guest's pages are to be moved to another level of storage. Inactive guest PP
The R-log is processed on the assumption that the page is not checked at some time and the release of resources avoids the need to steal the page from active guests. Guest logs are also processed prior to intended page stealing and extended storage migration, both in the form of page migration in the VM / ESA system 10.

If the CMSSM 20 reuses the page before the CPRSM 22 begins processing the PPR log, the page cannot be released. Therefore, CMSSM
There is a need for a mechanism for the CPRSM to determine if a page or a range of pages previously placed in a pending lease state has been reused.

To process the PPR log 44, the remaining entries are treated as standard page release status. For log processing, guest address space serialization,
There is a page release for each page identified by the log, and an address space serialization release. Optionally, the actual storage device containing PPR log 44 may be returned to system storage. In VM / ESA systems, CPRSM releases logs when guests are dropped from an active queue.

The actual process of page release should not be different from the process performed in prior art systems and should be within the skill of those in the art. Therefore, this will not be detailed here.

In the VM / ESA system 10, the PPR log 44 is processed when the guest's page is stolen or when the guest goes idle. In either case, the guest is unlikely to be dispatched immediately. Therefore, assuming that at least one purge is performed before this user's final dispatch, purging of the address translation buffer (TLB) may be avoided. VM with purge TLB scheduling
In / ESA system 10, BPR reduces the TLB purging rate from thousands per second to tens per second.

The substantial amount of time spent processing prior art page releases is the overhead of reaching the page release processor and setting up addressability to the proper address space and other housekeeping tasks. Is. In the prior art, this overhead was generated with each page release. In PPR,
The overhead can be distributed over several releases. If deferral comes to avoid avoiding releases altogether, even greater benefits result. This happens if the pending release is canceled before the log is processed.

FIG. 5 shows a pseudo code fragment for a program module that processes the PPR log 44. When a guest is dropped from the active queue (line 201), its PPR log 44 is processed to reclaim its unusable page (line 20).
2). Since the guest is idle for a while, PP
The storage used for the R log is also returned (line 2
03), reusing the storage device used to store the PPR log itself.

Guests are selected for migration (line 2
05), but if it remains active, its PPR log 44 is processed. However, the log is not returned to system storage so that the guest can continue to make log entries.

Before processing the log 44, there is no other real machine CPU that performs some other operation that may translate in the address space or conflict with page releases in a multiprocessing environment. Address space serialization is required to ensure that (line 206). For each page of the log (line 207), all resources are reused and returned to the system, leaving the page blank. Finally, address space serialization is released (line 209).

To further summarize, there are two times when the PPR log 44 is processed, namely when the guest is inactive and when the guest page is about to be migrated. Processing the log only involves reusing all resources and leaving the page blank.

Suspended pager with optional services
Lease Cancellation The preferred method for the host to determine if a guest has reused a page that is in a pending release state is a guest notification that the goal is to reuse the page. The notification is achieved by the guest requesting a PPR cancel operation.

In order to specify the PPR cancel operation,
The sub-function code 40 is set to 1. The range of pages involved in the PPR operation is specified by bits 1-19 of the odd-even register pair RX (28) and RX + 1 (34), just as described above.

6 and 7 include pseudocode fragments for a program module that cancels pending page releases and handles the request for all optional services. Lines 301-305 describe the actions taken by the CMSSM 20 before the execution of the PPR instruction, while lines 306-314 describe the actions of the CPRSM after execution and shutdown of the PPR instruction.

First, CMSSM 20 determines whether it will reuse the page currently in the pending release state (line 301). The CMSSM 20 then sends the bottom page within the even register RX28 (line 302), the top page within the odd register RX + 1 (34) (line 303), and the subfunction code 40 of 1 (line 30).
Prepare to issue the PPR / DIAGNOSE command 24 specifying 4). CMSSM20 is DIAGNOSE
An instruction is issued (line 305), resulting in an instruction block and control is sent to CP 14.

After the command is cut off, the cause of CP14 is D
It is determined whether it is an IAGNOSE214PPR instruction (line 306). If so (line 3
07), the PPR sub-function code 40 is checked. PP
If the R operation is not cancelled (if the PPR operation is not set and the pseudo code line 107 has already been determined), then an invalid PPR sub-function code is specified and the specified exception is indicated to the CMSSM guest (line 31).
3).

Although PPR cancellation is requested,
However, if there is currently no PPR log 44, there is nothing to cancel next (the log is being processed or the guest is trying to cancel it without setting a release), and the SIE returns control to the CMSSM guest. (Line 308). Otherwise, each log entry is examined (line 309) and if all the pages in a log entry are within the cancel range, that entry is deleted (line 310). If the subset of pages in the entry matches the cancellation scope, then the entry is updated to remove the canceled entry (line 311). Finally, CMSSM is re-invoked by the re-interpret execution mode (line 312).

In summary, when the CMSSM 20 receives a request for storage and determines that the request should be served by using the page or pages currently in the pending release state, the CMSSM 20
Must first cancel the pending release. The CPRSM 22 updates the PPR log 44 so as not to include any designated page,
Respond to this request by calling SSM again.

Operation Example In FIG. 8, the CMSSM 20 sends the PPR command to the CPRSM2.
Set and cancel pending page release by issuing to 2 and batch page release (BPR) by CPRSM processing the PPR log.
An example of changes to the PPR log when executing

At time A, there is no active entry in the PPR log 44, indicating that the associated address space has no pages in the pending page released state.

At time B, the CMSSM 20 has the PPR
-Issue the DIAGNOSE instruction 24 and register R
2. By specifying R3, the address X'2340
Request a PPR set operation for the page range between 00 'and X'23F000'. Subfunction code 40 of register R3 is set to zero to specify a PPR set operation and the first 19 bits of registers R2 and R3 are the start and end addresses X'234000 'and X'2.
Identify 3F000 '. After processing the DIAGNOSE instruction as described above with reference to FIGS. 3 and 4, PP
The first entry 48a in the R log 44 identifies these pages as being in a pending release state.

At time C, CMSSM 20 also requests a PPR set operation using registers R2 and R3,
At this time, the page is identified from address X'240000 'to address X'241000'. Since these pages are adjacent to the one specified by the existing log entry 48a from time B, its entry 4
8a is modified to show the merge range of the page.

At time D, the PPR is page X'130.
000 'to X'140000'.
These pages are not adjacent to any existing entry, so a new entry 48b is created.

At time E, the CMSSM 20 wants to reuse two pre-released pages, X'130000 'and X'140000', and requests that their pending releases be canceled.
The PPR log 44 indicates that at time E these pages are removed from the pending release state.

Next, at time F, CMSSM requests that page X'137000 'be reused.
At this time, the PPR log 44 is page X'137000 '
X'130000 'to X'13 at time E to indicate that is not already in pending release state
It is shown that the previous entry 48b specifying up to E000 'is divided into two entries 48b and 48c at time F.

At time G, CMSSM returns page X'13.
We want to reuse 0000 'to X'136000'. At this time, the PPR log 44 indicates that the entry has been removed and the log has been compressed.

Finally, at time H, CPRSM 22 decides to release the page in the pending release state and processes PPR log 44 as described above. CPR
If the SM is processing the PPR log before migrating from the guest, the actual log will be saved. Otherwise, the log is abandoned when the guest goes idle.

Advantages of the Invention The batch page release (BPR) of the present invention has several distinct advantages over prior art systems that make page release entirely impossible. In particular, the System Storage Manager (SSM) processes its PPR log before selecting an address space for migration. In this way, the resources of the page in the pending release state are reused without requiring any migration. If the system request for storage resources is not met by this reuse, the SSM will continue to migrate any of the remaining pages that meet the migration criteria. The PPR log may also be processed when a guest goes idle or enters a state where it is unlikely to reuse its unusable pages for some time. This releases idle resources to be used by active guests or CPs.

The present invention provides a number of important advantages over the known prior art page release systems described in the "Prior Art" section above. These advantages are as follows.

1. When the pending page release is set,
It's just logged. The system may then process the log, if it sees fit, perhaps in response to a system request or when the owner becomes inactive. In some systems with sufficient storage resources, no action other than logging may be required. 2. The TLB entry should only be considered when the log is processed and the main memory page is actually released. When the pending page release is set, no main memory page is actually released, so the guest is called again with all TLB entries intact. 3. Once processed, the PPR log generally summarizes multiple pending page release requests. This means that the fixed costs (including address space placement and serialization) are extended over more demands. In addition, between pending page releases and PPR log processing, many pending releases are canceled and no additional processing is required. 4. Prior art page releases, such as those performed in VM / ESA, do not at the address space level,
Serialization is required for each page release. This allows another system function, the most prominent page steal, to operate on unlocked pages in space. However, uneconomical serialization instructions, ie compare and swap, are required to be performed for each page released. In BPR, address space level locks are obtained before performing a batch page release. This reduces the number of serialization instructions required.
This lack of granularity is not detrimental because the PPR is processed before performing page stealing for guests.

Other Embodiments In another other first embodiment, the PPR log may be replaced with a guest and system addressable bitmap. Each page suitable for a pending release is represented by two bits in the map.
One of these bits indicates that the associated page is in a pending release state and is set on by the guest to set the pending release and set off by the guest to cancel the release. Will be done. The other bit will indicate to the system that the pending release has been set for the page, but has not yet been processed, even if it has not been cancelled. This latter bit is set on by the guest when setting the PPR and off when the system handles the release.

When the system processes the bitmap,
If both bits indicating that the page is currently in the pending release state are on, then all resources are reclaimed and the page is left blank. If only one bit is on (the release has been canceled by the guest, but has not yet been processed by the system), further main storage is left in place, but released All other copies representing versions (eg DASD, extended storage) will be reused for that purpose. This guarantees that the system will never migrate the contents of a page in pending release.

The advantage of this embodiment is that the guest can update the log without the intervention of any control program. This is especially important when the guest is operating in interpretive execution mode. The reason is that it takes a considerable amount of time to get in and out of that mode.

This technique has some disadvantages. First, the recovery of non-storage resources is delayed. Second, maps take up more space than logs.
Finally, if the system has only long-running (expensive) instructions to process the bitmap, excessive CPU time will be spent on logging.

In a second alternative embodiment, instead of completely processing the user's log before migrating the page, it is determined whether the page selected for migration is in the pending release state. It just inspects the logs. In this example, migration is avoided and backing resources are immediately reused. Bitmaps with direct indexing
It is most effective when such a scheme is used. V
Since M / ESA migrates all available pages from the address space before moving to the next address space, complete processing of the log before migration is more efficient than log inspection. This inspection technology sweeps the main memory,
It is more effective for systems that approach migration, unlike systems that do not batch by address space.

In an alternative third embodiment, the real machine can perform the PPR operation described above as being executed by the host. As in the second and other embodiments above, this avoids control program intervention. The disadvantage is the required microcode and hardware capacity and immutability of the implementation.

In the other fourth embodiment, the entire PPR is used.
Instead of processing instructions, the real machine has RX and RX + 1
It only logs at the next available log entry by storing. An interrupt (or command break) is the result when the log is full or does not exist. Periodically, the host processes the logs and immediately reclaims non-main storage,
Prior to the migration or when the guest goes idle, another log of pending storage main storage pages to be processed will be generated. It also avoids control program intervention and requires substantially smaller microcode and / or hardware than a full implementation. The disadvantage is the delay in reclaiming non-storage resources.

In another fifth embodiment, the machine is PP
It can be logged with the next available log entry for the R set operation only. An interrupt (or command break) is the result when the log is full or does not exist. When the guest exits the interpretive execution mode (due to an unrelated shutdown or interrupt), the system processes the log to reclaim non-main memory. The PPR cancel operation continues to cause command interruption. This embodiment allows the use of optional services, while reducing the number of supervisor calls.

In another sixth embodiment, guest page reuse detection is done by checking the page's change bit, which is set to zero at PPR setting. When the guest reuses the page, the change bit is set to 1 and the system does not actually release the page. In this example, the need for the guest to request a PPR cancel operation would be avoided. The disadvantage of this embodiment in the VM / ESA system is that setting the change bit requires the SSKE instruction, which is very expensive.

The other seventh embodiment does not have a positive check to detect if the guest decides to reuse a page in the pending release state, rather it never matches once the page is released. That is, to let the guest follow a protocol that will never be done.

While the user is described as a guest program running in a virtual machine maintained by a host control program, the work of requesters and releasers is performed by other parts or programs of the system, and by different elements of the same program. It will be appreciated that it can be implemented. In this way, any program, including applications and operating systems, can perform the functions of a requestor, albeit perhaps not like a user storage manager such as the CMSSM described above. Further, the present invention is applicable to all types and units of storage released by and returned to users, and although the present invention is the earliest adapted to virtual storage management, virtual storage. Not immediately applicable to device pages.

Finally, although the preferred embodiment has been described in a method for setting and canceling a pending page release request, and further processing the pending page release log, while appropriate for operating as described above. It is envisioned to be embodied in a programmed computer system (device). One such example of the preferred embodiment includes an IBM System 370 / ESA computer, such as an IBM 3090 series computer loaded into the IBM VM / ESA operating system as described above.

It is further envisioned that the present invention is embodied in a pre-recorded computer program for programming a computer to set, cancel and process pending page release requests as described above. One such example of the preferred embodiment is on a conventional data storage medium, such as a magnetic tape, and on a tape that will cause the system to set, cancel and process pending page release requests as described above when implemented on a suitable computer system. It contains a series of instructions recorded in.

[0081]

Since the present invention is configured as described above, a computer virtual storage device management system having a plurality of storage devices, such as pages, at least one of which is assigned to a user of the system such as an application program or a guest operating system. We can offer batch releases for you.

[Brief description of drawings]

FIG. 1 is a block diagram of a VM / ESA computer system including a storage manager (CMSSM) according to a preferred embodiment of the present invention.

2 is a register format of a pending page release instruction of the system of FIG.

3 is a pseudo code fragment for establishing a pending page release in the system of FIG.

4 is a pseudo code fragment for establishing a pending page release in the system of FIG.

5 is a pseudo code fragment for processing a log of pending page releases in the system of FIG.

6 is a pseudo code fragment for canceling a pending page release in the system of FIG.

7 is a pseudo code fragment for canceling a pending page release in the system of FIG.

FIG. 8 is a diagram showing an example of changes in the log of FIG. 5 when a pending page release is established and canceled.

[Explanation of symbols]

 10 VM / ESA System 12 Real Machine 14 VM / ESA Control Program (CP) 16 VM / ESA Interactive Monitoring System (CMS) 18 Virtual Machine 20 CMS Storage Manager (CMSSM)

Claims (5)

[Claims] 1. A method of managing a storage device assigned to a user of a computer system, the method comprising: (a) identifying to the system at least a first storage device to be released by the user; b)
The system placing the first storage device in the pending release state; (c) the system suspending the release of the first storage device; and (d) at least the second storage device to be released by the user. The user identifies to the system, (e) the system places the second storage device in the pending release state, and (f) the system performs the second.
Storage device management method, including the step of postponing the release of the storage device of (1), and the step of (g) releasing the first and second storage devices by the system. 2. The method further comprises step (h) wherein the system detects whether the user has decided to reuse a selected one of the first or second storage devices, and step (g). 2. The storage device management method according to claim 1, wherein the method releases the selected storage device only when the user does not decide to reuse the storage device. 3. A computer system for executing a user program, comprising: (a) a plurality of storage devices in which at least two storage devices can be assigned to a user; and (b) at least a first storage device assigned to a user. And a first module responsive to the user to continuously place the second storage device in the pending release state, and (c) releasing the at least first and second storage devices in the pending release state. A second module and a computer system. 4. A third module for detecting whether the user has decided to reuse one selected from the first and second storage devices in the pending release state. The second module releases the selected storage device only if it is detected by the third module that the user did not decide to reuse the storage device. Responding to the module
The computer system according to claim 3. 5. An article of manufacture for use in a computer system having a plurality of storage devices assignable to and releasable from a user program, the record being for recording a computer program executable on the system. A medium; a first module responsive to the user to continuously place at least first and second storage devices allocated to the user in a pending release state; and the at least first and second storage in a pending state A second module for releasing the device; wherein the first and second modules are recorded on a medium and are executable on the system, the article of manufacture for use in a computer system.