Method and apparatus for a high performance operating system in a RIPL environment
Original Publication Date: 2001-Mar-01
Included in the Prior Art Database: 2003-Jun-17
A Remote IPL System (RIPL) is one where a (set of) client computer(s) is/are installed without a locally installed operating system, such as Microsoft Windows, or OS/2. In some cases, these systems may not even have a local hard disk. When these systems start, they broadcast a network request for a "boot" server. If there is a server on the network that can boot such as system, they negotiate and the operating system code is downloaded from the server to the client, in some cases with user logon and personalization. The problem inherent in this design is that the operating system and application code does not reside locally on the client. Most of the current systems today, such as OS/2 and Windows are virtual memory systems. Specifically, they allow the use of more memory than is physically present in the computer. When code, such as application code or operating system code meets the "discard" criteria (has not been accessed recently, so it can be discarded and reloaded later) it is discarded from memory. This means that when this piece of code is later needed, it must be reloaded from the hard disk; in the case of a RIPL system, over the network from the server. Herein lies the problem. The code takes longer to be loaded over the network from a server than from a local hard disk. This creates performance problems for overall system throughput, especially for memory constrained systems where code discarding is frequent. Additionally, code segments that are loaded multiple times during a boot or start up sequence cause initial system load or IPL, to take longer as well. The solution to this problem, and the focus of this disclosure is a method to mitigate the performance impact of this situation, while preserving the goal of the RIPL environment, which is to lower the administration costs of the client systems. This solution applies to systems with local (but limited) hard disks. While some RIPL configurations have clients with no local hard disk space, many have small local hard disks for data swapping (memory overcommitment for data, where it is swapped to disk, rather than discarded code does not change, while data does, so data in overcommitted memory gets swapped real-time to disk to be later reloaded, but code is discarded and reloaded from it's original source).