Previous Table of Contents Next


Although the answer may be obvious to most of you, a question often asked is, “Why does the virtual address have to get down to the byte level? Why can’t it just address objects like instructions at the MI do?” To fully answer this, we need to realize that the processor hardware in the AS/400 (either the CISC or RISC models) is fairly conventional. The processor addressing mechanism shown in Figure 8.1 knows nothing about objects. As we saw in Chapter 1, a processor gets instructions and data from memory. The MI system objects are located in memory and the processor uses byte addressability to get at the information contained in these objects: records in a file, instructions in a program, and so on. An IMPI processor uses the original 48-bit virtual address, which it translates to a real address to access the memory. To access the memory, a PowerPC processor uses the effective addresses we have discussed and translates these addresses first to virtual and then to real. Hardware registers in both processors keep track of the next instruction in the program to execute and the addresses of data being used.

A page previously brought into memory by one process (job) is available to any other process. Program instructions can be shared by any number of jobs. Recently read records from the database are likely to be in memory. Disk I/O is greatly reduced if the same records are read many times. Suppose, in our database read example, we are using an index that is shared with other users in the system. If that index recently has been used by one of those other users, part or all of the index is likely to still be in memory and we will not have to wait while index pages are fetched from disk. In a conventional system with more limited sharing, a new copy of the index would have to be brought into memory even though one might already exist.

Given a virtual address, the hardware looks first to see whether the corresponding page is already in memory. If it’s there, the hardware uses the page in memory. If not, a page fault has occurred, which means the missing page must be retrieved from disk.

The translation of a virtual address into a real address is to find the page frame in memory corresponding to the virtual address. This virtual-to-real translation uses a page table that is located in memory. The hardware’s search of the page table uses a hashing algorithm (which we describe later in this chapter) to locate a page table entry group (PTEG). Each PTEG contains eight page table entries, and these are searched individually to see whether the sought-for page has a match. If not, a page fault occurs — a hardware interrupt that signals the SLIC main storage management component to find the disk address corresponding to the virtual address and to instruct an I/O processor to go out to disk and retrieve the page.

To speed the search for recently used pages, a set of registers exists on the processor chip, called the translation lookaside buffer (TLB), that holds the most recently used entries in the page table. Because the TLB registers are built into the processor, a load from memory (where the page table is located) is not required if the virtual address points to a recently used page. If the virtual address is not there, a second stage of the translation process has the hardware look in the page table located in memory.

The PowerPC processors used in the latest AS/400s also can operate in the tags-inactive mode. This mode is never used for OS/400, but for completeness, the addressing description is included here. If the PowerPC processor is operating in the tags-inactive mode, the hardware first looks at the segment look-aside buffer (SLB), another set of registers on the processor hardware chip that holds the most recently used parts of the segment table. If there is no match in the SLB registers, the hardware looks at the segment table in memory before going to the TLB registers and the page table. In other words, in the tags-inactive mode a three-step translation process occurs — effective-to-virtual-to-real.

In the event of a page fault, to send the message to the I/O processor, the SLIC uses another kind of address called a direct store address. Such addresses are used to communicate with any external device. These addresses begin with the hexadecimal value 801. Part of the direct store address is passed directly to the process managing the external device.

When a page is brought from disk, it replaces a page not recently used. Special reference bits associated with each page are set whenever the page is referenced. Pages that have been changed are also marked, so that when they are replaced they are written back to disk.

Memory contains program instructions, data, and pointers. Data in this case means anything that’s not an executable instruction and not a pointer. This would include all non-program OS/400 objects, as well as parts of program objects that are not executable. Contrast this with the distinction made on the WRSYSSTS (Work With System Status) display between database and nondatabase page faults. Database means strictly physical and logical files. Nondatabase faults refer to all other objects. In our sequential read example, any page faults for the program, cursor, or any space would be considered nondatabase page faults.

In the preceding paragraphs, we have looked at page faults. It is not necessary to wait for a page fault to read a page in from disk. Any SLIC component or any translated MI program can request the main storage management component of SLIC to explicitly bring (read) a range of virtual pages (one or more) into memory. Functionally, it is never necessary to explicitly bring pages into memory, because the required pages will always be brought in as the result of page faults. When a page fault occurs, the process incurring the fault waits for the disk read to complete. Requesting a bring operation before the pages are needed allows the disk read operations, which may take a long time, to occur overlapped with other processing. Brings can improve performance.

It is also possible to explicitly create clear page frames in memory. A clear request to main storage management results in one or more page frames in memory set to binary zeros. This is a useful operation when, for example, a buffer is going to be filled with new data and you don’t care about its current contents on disk. Rather than reading in the pages of the buffer with individual page faults or even with a single bring, the clear operation gives page frames set to binary zero without performing a single disk read operation.


Previous Table of Contents Next

Copyright © NEWS/400 Books