Patent Application
20080120480
1. Field of the Invention
This invention generally relates to memory management in a computer system, and more specifically, to preserving critical storage contents across a system restart.
2. Background Art
In a typical computer system, tables that reside in memory may hold some critical contents that need to be preserved across a system restart (provided that memory is not cleared as part of the restart). If such a table is small, infrequently updated, and its contents do not include memory addresses (such as table chain pointers), it can be reasonable to simply file out the table contents periodically. During system restart, the filed out table can be copied to whatever memory gets allocated for the table. If the table does contain memory addresses, then the table either needs to be copied into the same memory locations or, if possible, the memory addresses in the table need to be updated based on the table's new location in memory. In all of these cases where the table is filed out, it is possible that the file copy may not match the table contents in memory at the time when a system restart is performed.
Another possible solution is provided by having the operating system map virtual addresses to the same real storage on each system restart. Additional code is then written to verify that the table still resides at the same virtual addresses (and therefore at the same real storage addresses). If the table address in memory is different, then the table contents have been lost and table initialization is required.
An object of this invention is to preserve critical storage contents, in a computer system, across a system restart.
Another object of the present invention is to preserve virtual addresses and their corresponding storage contents for critical system tables across a system restart.
A further object of the invention is to update storage allocation APIs to specify a request for specified recoverable storage and to use an operating system to save virtual and real storage address information about that specified recoverable storage allocation.
These and other objectives are attained with a method and system for a computer operating system to allocate “recoverable” memory for a table. The invention involves updating storage allocation APIs to specify a request for “recoverable” storage and for the operating system's saving of virtual and real storage address information about the “recoverable” storage allocation. On a subsequent system restart, when the recoverable storage allocation is again requested, the operating system will use the saved information to rebuild the required virtual address space mappings (virtual addresses to backing real storage) to reallocate the same virtual and real storage. The operating system preferably also tracks requests for memory, which is not deemed “recoverable”, and avoids allocating virtual and real storage addresses, which are being used for “recoverable” storage requests.
The preferred embodiment of the invention, described below in detail, provides a number of important advantages. These include:
Further benefits and advantages of this invention will become apparent from a consideration of the following detailed description, given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention.
Initialization of the computer system is performed upon power-up of the computer system or hardware or software reset operations. In one boot scheme, the processor is designed to read a pre-determined memory location when the processor is reset or powered up. The pre-determined memory location stores a pointer or an address, which directs the processor to a memory address of the beginning of the bootstrap routines. The pointer or address is referred to as a boot vector.
As indicated above, for system critical tables that reside in memory, there can be a need to preserve table contents across a system restart. The present invention addresses this need by preserving virtual addresses and their corresponding storage contents for critical system tables across a system restart.
In computer systems, it is customary that there be one-to-one correspondence between the memory address produced by the processor and a specific area in the physical memory of the system. It is an error for the processor to request access to an address, which does not have an associated physical memory area. This limits the operating system and applications to an address space determined by the actual physical memory installed in the system. Modern computer systems have overcome this limitation through the use of virtual memory, which implements a translation table (TT) to map program (virtual) addresses to real memory addresses.
With virtual memory, the program works in an address space limited only by the processor architecture. It is a function of the operating system to ensure that the data and code a program is currently using is in main memory and that the translation table can map the virtual address to the real address correctly. In a virtual memory system, the allocation of memory is most commonly performed by the operating system software.
In accordance with the preferred embodiment of this invention, when an operating system is first started, storage is allocated for various system tables. In order to preserve this storage on subsequent system restarts, the operating system provides a system service call (assembler macro, C/C++ function, etc.), which can be used to request “recoverable” storage. The preferred “get_storage” service, as shown in
Size of the storage allocation request (input from caller);
Unique name or tag to associate with the storage request (input from caller);
Recoverable/non-recoverable storage flag (input from caller);
Starting virtual storage address (output returned to caller); and
Success/failure flag on recovering requested storage (output returned to caller).
The get_storage service routine of
In order to recover storage allocations on subsequent system restarts, a “storage recovery” table (SRT) is needed to hold information on each recoverable storage allocation. An example SRT is represented in
Unique name or tag associated with the storage;
Starting virtual storage address;
Size of the storage allocation;
Starting real storage address;
Ending real storage address; and
Gaps in real storage allocated.
The SRT is kept in real storage and it is not mapped in the virtual address space being constructed by the operating system. This is done to limit the possibility of SRT storage corruption. The real storage address of the SRT is kept on file and is retrieved from file by the operating system during the initial phase of a system restart.
In addition, a “system storage allocation” table (SSAT) is used, during system restart, to hold information on current virtual and real storage resources available for storage allocation request (both recoverable and non-recoverable storage). An example of an SSAT is shown in
Next available virtual storage address;
End of available virtual storage;
Next available real storage address;
End of available real storage address;
Gaps in range of available virtual storage addresses; and
Gaps in range of available real storage addresses.
A virtual address mapping is built using virtual and real storage information in the SSAT, virtual and real storage information are updated in the SSAT, and the starting virtual storage address is set up in the caller's output area. If this is a new recoverable storage request, the required storage information is saved. In particular, the storage name and size, and the virtual and real storage information are saved in the SRT entry.
The present invention, in its preferred embodiment, provides several important advantages. Among these are:
As will be readily apparent to those skilled in the art, the present invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer/server system(s)—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general-purpose computer system with a computer program that, when loaded and executed, carries out the respective methods described herein. Alternatively, a specific use computer, containing specialized hardware for carrying out one or more of the functional tasks of the invention, could be utilized.
The present invention, or aspects of the invention, can also be embodied in a computer program product, which comprises all the respective features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program, software program, program, or software, in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.
While it is apparent that the invention herein disclosed is well calculated to fulfill the objects stated above, it will be appreciated that numerous modifications and embodiments may be devised by those skilled in the art, and it is intended that the appended claims cover all such modifications and embodiments as fall within the true spirit and scope of the present invention.
