System and method for improving the page crossing performance of a data prefetcher

A system and method for improving the page crossing performance of a data prefetcher is presented. A prefetch engine tracks times at which a data stream terminates due to a page boundary. When a certain percentage of data streams terminate at page boundaries, the prefetch engine sets an aggressive profile flag. In turn, when the data prefetch engine receives a real address that corresponds to the beginning/end of a new page, and the aggressive profile flag is set, the prefetch engine uses an aggressive startup profile to generate and schedule prefetches on the assumption that the real address is highly likely to be the continuation of a long data stream. As a result, the system and method minimize latency when crossing real page boundaries when a program is predominately accessing long streams.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to a system and method for improving the page crossing performance of a data prefetcher. More particularly, the present invention relates to a system and method for identifying a time at which a data stream's prefetched cache lines approach the end of a real page, and aggressively prefetch the data stream's subsequent cache lines that resume on a different real page of data.

2. Description of the Related Art

Microprocessors use a prefetch engine to anticipate upcoming program requirements for data located in distant caches and system memory. By using a prefetch engine, a microprocessor prefetches data and locates the data in local cache when the program calls for the data. This mitigates substantial latency associated with retrieving the data if, instead, the microprocessor waits until the program calls for the data.

A microprocessor may use a data stream prefetch engine to detect data streams, which may be defined as a sequence of storage accesses that reference a contiguous set of cache lines in an increasing or decreasing manner. In response to detecting a data stream, a prefetch engine is configured to begin prefetching data up to a predetermined number of cache lines ahead of the data currently in process. Data stream prefetch engines, however, are often implemented such that they prefetch only up to the end of a real page of data, which greatly simplifies their implementation due to the fact that the prefetch engines are not required to track effective addresses of the data streams or retranslate addresses within a data stream.

A challenge found is that when a data stream crosses a page boundary, the continuation of the stream in a new real page appears like a new data stream altogether. In current implementations, a new stream startup profile is typically “conservative” in nature. A conservative startup profile does not start prefetching cache lines until the application loads data that causes at least two consecutive cache lines to miss the cache, and begins prefetching ahead of the line currently being loaded by the program slowly, gradually prefetching farther ahead as the application loads more and more lines along the stream until it is prefetching the desired lines ahead of the demand loads.

For example, when an existing prefetch engine is in a conservative, or “normal” startup profile and a program loads line “I,” the prefetch engine speculates that the program might next load line I+1 and record the address for line I+1 in a prefetch request queue. When the program sometime later loads an address in line I+1, the prefetch logic detects the load and might send an L1 prefetch for line I+2 while also setting the address in the prefetch request queue to line I+2 (advancing the address in the request queue to the next line it expects the program to load). When the program later loads an address from line I+2, the prefetcher might send an L1 prefetch for line I+3, and L2 prefetches for lines I+4 and I+5, etc. Note, however, that the prefetch engine does not prefetch across a page boundary. As such, once the prefetch engine reaches a page boundary, the prefetch engine terminates its prefetching.

A challenge found is that for a long stream that crosses one or more page boundaries, the data stream interruption and the process of reacquiring the data stream impairs performance by adding stalls equal to multiples of the memory latency due to added cache misses at the beginning of each page and the re-ramping of the prefetches.

What is needed, therefore, is a system and method that improves the page crossing performance of a data prefetch engine.

SUMMARY

It has been discovered that the aforementioned challenges are resolved using a system and method for using an aggressive startup profile when a program accesses a cache line at a new page boundary and a suitable percentage of prior data streams have terminated at page boundaries. A prefetch engine tracks times at which a data stream terminates due to a page boundary. When a certain percentage of data streams terminate at page boundaries, the prefetch engine sets an aggressive profile flag. In turn, when the data prefetch engine receives a real address that corresponds to the beginning/end of a new page, and the aggressive profile flag is set, the prefetch engine uses an aggressive startup profile to generate and schedule prefetches due to the fact that the real address is highly likely to be the continuation of a long data stream. As a result, the system and method minimize latency when crossing real page boundaries when a program predominately accesses long streams, and switches back to a normal startup profile when data streams are short and less frequently crossing page boundaries.

A load store unit receives a load or store instruction from instruction memory. When the instruction is a load instruction, the load store unit sends a corresponding real address to a prefetch engine. The prefetch engine receives the real address and checks whether a prefetch request queue entry located in a prefetch request queue includes a matching address.

When the prefetch engine identifies a matching address in one of the prefetch request queue entries, the prefetch engine advances the state of the matched prefetch request queue entry, which includes advancing the address in the matched prefetch request queue entry to the address of an expected next line in a data stream, and generating a set of prefetch requests according to its state. The prefetch engine then conditionally sets a page boundary value bit (register) based upon whether the stream terminates at a page boundary (e.g., the first/last line in a page for a descending/ascending stream, respectively).

When the prefetch engine determines that the real address is not included in one of the prefetch request queue entries, the prefetch engine detects whether the real address corresponds to a cache line currently within an L1 data cache or whether the real address is included in a load miss queue. If either instance is true, thus indicating that the real address has been previously processed, the prefetch engine disregards the real address and waits for another real address to process. When the real address does not correspond to a cache line currently within the L1 data cache and is not included in the load miss queue, the prefetch engine proceeds through a series of steps to determine whether to start prefetching based upon a normal startup profile or an aggressive startup profile.

First, the prefetch engine selects a prefetch request queue entry located in the prefetch request queue based upon a least-recently-used (LRU) algorithm to install an address corresponding to a next expected address (either N+1 if the stream is predicted to be ascending or N−1 if the stream is predicted to be descending). The LRU algorithm identifies a prefetch request queue entry that has not had an address match in the longest number of cycles compared with the other prefetch request queue entries. The prefetch engine then pushes a page boundary value of “0” or “1” from the entry's page boundary value bit into a FIFO queue and resets the page boundary value to “0”.

Next, the prefetch engine computes a “historical page boundary percentage” by calculating the percentage of page boundary values included in the FIFO queue that are “1” versus those that are a “0.” The calculation identifies the percentage of times that a previous address historically reached a page boundary. Once calculated, the prefetch engine determines whether the historical page boundary percentage is greater than a historical page boundary threshold, such as 70%. When the historical page boundary percentage is greater than the historical page boundary threshold, the prefetch engine sets an “aggressive profile flag.” Next, the prefetch engine identifies whether the address is the first or last cache line in a page and if so, whether the predicted direction is compatible with a data stream (e.g., if the address is the first cacheline in a page and the data stream is ascending).

When the address is a candidate for an aggressive startup profile and the aggressive profile flag is set, the prefetch engine generates and schedules a set of prefetch requests according to an “aggressive” startup profile, which minimizes latencies and improves the data stream's page-crossing performance.

DETAILED DESCRIPTION

FIG. 1is a diagram showing a prefetch engine tracking times at which data streams reach a page boundary, and aggressively prefetch cachelines at the start of prefetching data from a new real page when a historical page boundary percentage exceeds a historical page boundary threshold.

Load store unit100receives a load or store instruction from instruction memory105. When the instruction is a load instruction, load store unit100sends corresponding real address130to prefetch engine140. Prefetch engine140receives real address130and checks whether a prefetch request queue entry located in prefetch request queue150includes a matching address.

When prefetch engine140identifies a matching address in one of the prefetch request queue entries, prefetch engine140advances the state of the matched prefetch request queue entry, which includes advancing the address in the matched prefetch request queue entry to the address of an expected next line in a data stream, and generating a set of prefetch requests according to its state. For example, if the current real address included in the prefetch request queue entry corresponds to cache line N, then processing replaces N with an address of line N+1 for an ascending stream, or with an address of line N−1 for a descending stream. Some of the prefetch requests may be targeted for L1 cache110, and others may be targeted for L2 cache170.

In a special case where the address from the load is the last line in a page for an ascending stream, or the first line in the page for a descending stream, a page boundary value bit (register) included in the prefetch request queue entry is set to a “1”, otherwise it is left at a value of “0”. This value is later used to determine the start-up profile of a new stream (discussed below).

When prefetch engine140determines that real address130is not included in one of the prefetch request queue entries, prefetch engine140detects whether the real address corresponds to a cache line currently within L1 data cache110or whether the real address is included in load miss queue120. If either instance is true, thus indicating that real address130has been previously processed, prefetch engine140disregards real address130and waits for another real address130to process.

When the real address does not correspond to a cache line currently within L1 data cache110and is not included in load miss queue120, prefetch engine140proceeds through a series of steps to determine whether to start prefetching based upon a normal startup profile or an aggressive startup profile. First, prefetch engine140selects a prefetch request queue entry located in prefetch request queue150based upon a least-recently-used (LRU) algorithm to install an address corresponding to a next expected address (either N+1 if the stream is predicted to be ascending or N−1 if the stream is predicted to be descending). The LRU algorithm identifies a prefetch request queue entry that has not had an address match in the longest number of cycles compared with the other prefetch request queue entries. Prefetch engine140then pushes the page boundary value of “0” or “1” from the identified entry's page boundary value bit into FIFO queue160and then resets the boundary value bit to “0”.

Next, prefetch engine140computes a “historical page boundary percentage” by calculating the percentage of page boundary values included in FIFO queue160that are “1” versus those that are a “0.” The calculation identifies the percentage of times that a previous stream address historically reached a page boundary (seeFIG. 5and corresponding text for further details).

Once calculated, prefetch engine140determines whether the historical page boundary percentage is greater than a historical page boundary threshold, such as 70%. When the historical page boundary percentage is greater than the historical page boundary threshold, prefetch engine140sets an “aggressive profile flag.” Next, prefetch engine140identifies whether the address is the first or last cache line in a page and if so, whether the predicted direction is compatible with a data stream (e.g., if the address is the first cacheline in a page and the data stream is ascending).

When the address corresponding to the load instruction is a candidate for an aggressive startup profile and the aggressive profile flag is set, prefetch engine140generates and schedules a set of prefetch requests according to an “aggressive” startup profile (seeFIG. 6and corresponding text for further details), which minimizes latencies and improves the data stream's page-crossing performance.

FIG. 2is a diagram showing effective addresses included in a data stream that are translated to discontiguous real addresses. A computer system translates effective addresses included in data stream200to real addresses during load operations in order to retrieve data from physical memory250.

Data stream200includes contiguous effective addresses. As can be seen, the number of effective addresses is larger than the number of cache lines that reside on a real page. As a result, data stream200spans across multiple real pages when translated. The example inFIG. 2shows that effective addresses210are translated to real page A260, and effective addresses220are translated to real page C280.

Data stream200includes effective address215and effective address225, which are contiguous addresses. However, since memory area270is not available, which may include one or more real pages, page A260and page C280are discontiguous. Therefore, when a prefetch engine receives a real address corresponding to effective address215, which is at a page boundary, the prefetch engine sets a page boundary value bit to “1”. This value is later pushed into a FIFO queue, such as FIFO queue160shown inFIG. 1(seeFIG. 5and corresponding text for further details) at the time the prefetch engine selects this queue entry for replacement.

FIG. 3is a diagram showing existing art conservatively prefetching cache lines at the beginning of each real page according to a “normal” startup profile, regardless of whether the prefetch requests are a continuation of a data stream corresponding to a different page.

When a prefetch engine is in a normal startup profile and a program loads line “I,” the prefetch engine speculates that the program might next load line I+1 and record the address for line I+1 in a prefetch request queue. When the program sometime later loads an address in line I+1, the prefetch logic detects the load and might send an L1 prefetch for line I+2 while also setting the address in the prefetch request queue to line I+2 (advancing the address in the request queue to the next line it expects the program to load). When the program later loads an address from line I+2, the prefetch engine might send an L1 prefetch for line I+3 and I+4, and L2 prefetches for lines I+5 and I+6, etc. Note, however, that the prefetch engine does not prefetch across a page boundary. As such, once the prefetch engine reaches a page boundary, the prefetch engine terminates its prefetching.

FIG. 3shows that at the beginning of a page (page305), existing art starts prefetching cache lines in a “Normal” startup profile, which prefetches a relatively small number of cachelines (set310). As the prefetch engine continues to prefetch, the prefetch engine gradually increases the number of cache lines in a set of prefetch requests (set320) until it is prefetching a predetermined number of lines ahead of the current load address. (set330).

However, when the data stream spans page break340and continues on a new page (page345), the prefetch engine reverts back to generating a small set of prefetch requests according to the “Normal” startup profile at the beginning of the new page (set350). This is due to the fact that the prefetch engine is tracking, for simplicity, real addresses in the prefetch request queues and there is a discontinuity in real addresses at the page boundaries as just described. In turn, existing art eventually increases the number of cache lines for a given set of prefetch requests (set360) until it completes prefetching cachelines (set370). As can be seen, added latency may occur because the prefetch engine generates a relatively small number of prefetch requests each time it begins a new real page, regardless of whether it is a continuation of a data stream that is in process of being retrieved.

FIG. 4is a diagram showing a prefetch engine aggressively prefetching cache lines at the beginning of a real page when the cache lines are speculated to be a continuation of a data stream that is in process of being retrieved.

The invention described herein starts prefetching cache lines according to a normal startup profile from page405(set410), and gradually increases the number of cache lines for a given set of prefetch requests (set420), until it is prefetching a given number of cache lines ahead of the current load address. (set430). When the prefetch engine detects that an address reaches a page boundary, such as the last line in a page, the prefetch engine pushes a page boundary value of “1” into a FIFO queue and resets the value of the bit to “0”. In turn, when the prefetch engine detects a new address at the beginning of a new page, the prefetch engine analyzes the page boundary values included in the FIFO queue to determine the likelihood that the new address is a continuation of a data stream. If so, the prefetch engine commences prefetching according to an aggressive startup profile (set450) until prefetching completes (prefetch460).

FIG. 5is a flowchart showing steps taken in processing a load instruction. Processing commences at500, whereupon processing fetches an instruction from a program in memory and decodes the instruction (step505). A determination is made as to whether the instruction is a load instruction (decision510). If the instruction is not a load instruction, decision510branches to “No” branch512, which loops back to fetch and decode another instruction.

On the other hand, if the instruction is a load instruction, decision510branches to “Yes” branch514whereupon processing sends a real address corresponding to the load instruction to a prefetch engine, such as prefetch engine140shown inFIG. 1(step515). The prefetch engine compares the real address with prefetch request queue entries included in a prefetch request queue, such as prefetch request queue150shown inFIG. 1.

A determination is made as to whether the real address matches an address included in one of the prefetch request queue entries (decision520). If the real address matches an address in one of the prefetch request queue entries, decision520branches to “Yes” branch522whereupon processing advances the state of the matched prefetch request queue entry, which includes advancing the address in the matched prefetch request queue to the address of the expected next line in the stream, and generating a set of prefetch requests according to its state (step525). For example, if the current real address corresponds to cache line N, then processing replaces N with an address of line N+1 for an ascending stream, or with an address of line N−1 for a descending stream.

A determination is made as to whether the address is at a page boundary, such as the first or last line in a page (decision530). If the address is at a page boundary, decision530branches to “Yes” branch532whereupon processing sets a page boundary value bit (register) included in the prefetch request queue entry to “1” (step535), which processing subsequently uses to select a prefetch startup profile (discussed below). On the other hand, if the address is not at a page boundary, decision530branches to “No” branch538bypassing page boundary value bit-setting steps.

Referring back to decision520, if the load instruction's real address does not match one of the prefetch request queue entries, decision520branches to “No” branch524, whereupon a determination is made as to whether the real address corresponds to a cache line currently within an L1 data cache, such as L1 data cache110shown inFIG. 1(decision550). If the real address corresponds to a cache line located in the L1 cache, no prefetch is required, no stream needs to be initiated, and decision550branches to “Yes” branch552, which loops back to process another instruction.

On the other hand, if the address corresponding to the load instruction is not located in the L1 cache, decision550branches to “No” branch558whereupon a determination is made as to whether the real address is included in a load miss queue, such as load miss queue120shown inFIG. 1(decision560). If the address is in the load miss queue, indicating that a load to the cache line has already been processed and/or a prefetch has already been requested for the real address, decision560branches to “Yes” branch562, which loops back to process another instruction.

On the other hand, if the address is not in the load miss queue, decision560branches to “No” branch568, whereupon processing selects a prefetch startup profile, such as a normal startup profile or an aggressive startup profile (pre-defined process block570, seeFIG. 6and corresponding text for further details).

A determination is made as to whether to continue processing (decision580). If processing should continue, decision580branches to “Yes” branch582, which loops back to process more instructions. This looping continues until processing should terminate, at which point decision580branches to “No” branch588whereupon processing ends at590.

FIG. 6is a flowchart showing steps taken in selecting a prefetch startup profile. In one embodiment, the invention described herein aggressively prefetches cache lines contingent upon specific historical stream information. In this embodiment, a page boundary value bit associated with each prefetch request queue entry is pushed into a FIFO queue upon selecting a prefetch request queue for a new stream. The M entries of 0 or 1 in the FIFO queue are used for qualifying new data streams as to whether they should be prefetched using a normal startup profile or an aggressive startup profile.

Processing commences at600, whereupon processing, at step610, selects a prefetch request queue entry based upon a least-recently-used (LRU) algorithm to install an address corresponding to a next expected address (either N+1 if the stream is predicted to be ascending or N−1 if the stream is predicted to be descending). The LRU algorithm identifies a prefetch request queue entry that has not had an address match in the longest number of cycles compared with the other prefetch request queue entries.

At step620, processing pushes the selected entry's page boundary value bit of “0” or “1” into FIFO160according to whether the selected PRQ entry had ended at the end of a page, and resets the page boundary value bit in the PRQ to “0” At step630, processing computes a “historical page boundary percentage” by calculating the percentage of page boundary values included in FIFO queue160that are “1” versus those that are a “0.” The calculation identifies the percentage of times that a previous address historically reached a page boundary (seeFIG. 5and corresponding text for further details).

A determination is made as to whether the historical page boundary percentage is greater than a historical page boundary threshold, such as 70% (decision640). If the historical page boundary percentage is not greater than the historical page boundary threshold, decision640branches to “No” branch642whereupon processing generates and schedules a set of prefetch requests according to a “Normal” startup profile (step680), and processing returns at685. On the other hand, if the historical page boundary percentage is greater than the historical page boundary threshold, decision640branches to “Yes” branch648whereupon processing sets an aggressive profile flag (step650), which processing subsequently uses as a determinant to set an aggressive startup profile (discussed below).

A determination is made as to whether the address corresponding to the load instruction is a candidate for an aggressive startup profile (decision660). First, processing checks the address to identify whether the address is the first or last cache line in a page and if so, whether the guessed direction is compatible with a data stream (e.g., if it the first line and ascending).

If the address corresponding to the load instruction is not a candidate for an aggressive startup profile, decision660branches to “No” branch662whereupon processing generates and schedules a set of prefetch requests according to a “Normal” startup profile (step680). On the other hand, if the address corresponding to the load is a candidate for an aggressive startup profile, decision660branches to “Yes” branch668.

A determination is made as to whether the aggressive profile flag is set (decision670). If the aggressive profile flag is not set, decision670branches to “No” branch672whereupon processing generates and schedules a set of prefetch requests according to a “Normal” startup profile (step680). On the other hand, if the aggressive profile flag is set, decision670branches to “Yes” branch678whereupon processing generates and schedules a set of prefetch requests according to an “Aggressive” startup profile (step690), and processing returns at695.

FIG. 7is a flowchart showing steps taken in an embodiment for identifying a time at which a data stream's prefetched cache lines approach a page boundary, and aggressively prefetching the data stream's subsequent cache lines that resume on a different real page of data. The flowchart shown inFIG. 7is a simplified embodiment of the invention described herein compared with the embodiment shown inFIG. 5.

Processing commences at700, whereupon processing fetches an instruction from a program in memory and decodes the instruction (step705). A determination is made as to whether the instruction is a load instruction (decision710). If the instruction is not a load instruction, decision710branches to “No” branch712, which loops back to fetch and decode another instruction. On the other hand, if the instruction is a load instruction, decision710branches to “Yes” branch714whereupon processing sends a real address corresponding to the load instruction to a prefetch engine at step715. The prefetch engine compares the real address with prefetch request queue entries included in a prefetch request queue.

A determination is made as to whether the real address matches an address included in one of the prefetch request queue entries (decision720). If the real address matches an address in one of the prefetch request queue entries, decision720branches to “Yes” branch722whereupon processing advances the state of the matched prefetch request queue entry, which includes advancing the address in the matched prefetch request queue to the address of the expected next line in the stream, and generating a set of prefetch requests according to its state (step725).

A determination is made as to whether the address is at a page boundary, such as the first or last line in a page depending upon whether the data stream is ascending or descending, respectively (decision730). If the address is at a page boundary, decision730branches to “Yes” branch732whereupon processing sets an aggressive profile flag at step735. Processing subsequently analyzes the aggressive profile flag to select a prefetch startup profile (discussed below). On the other hand, if the address is not at a page boundary, decision730branches to “No” branch734bypassing aggressive profile flag setting steps.

Referring back to decision720, if the load instruction's real address does not match one of the prefetch request queue entries, decision720branches to “No” branch724, whereupon a determination is made as to whether the real address corresponds to a cache line currently within an L1 data cache, such as L1 data cache110shown inFIG. 1(decision740). If the real address corresponds to a cache line located in the L1 cache, no prefetch is required, no stream needs to be initiated, and decision740branches to “Yes” branch742, which loops back to process another instruction.

On the other hand, if the address corresponding to the load instruction is not located in the L1 cache, decision740branches to “No” branch744whereupon a determination is made as to whether the real address is included in a load miss queue, such as load miss queue120shown inFIG. 1(decision745). If the address is in the load miss queue, indicating that a load to the cache line has already been processed and/or a prefetch has already been requested for the real address, decision745branches to “Yes” branch746, which loops back to process another instruction.

On the other hand, if the address is not in the load miss queue, decision745branches to “No” branch748, whereupon a determination is made as to whether the real address corresponds to a first line or a last line of a real page of memory (page boundary) (decision750). When the address corresponds to a first line or a last line of a page, the address may be a continuation of a data stream that is in process of being retrieved.

If the real address does not correspond to a first line or a last line in a page, decision750branches to “No” branch752whereupon processing generates and schedules a set of prefetch requests according to a “Normal” startup profile, and installs the real address in a prefetch request queue entry.

On the other hand, if the real address corresponds to a first line or a last line in a page, decision750branches to “Yes” branch753whereupon processing checks the state of the aggressive profile flag. As discussed above in this embodiment, processing sets the aggressive profile flag when an address included in a previous prefetch request reaches an end or a beginning of page boundary.

A determination is made as to whether the aggressive profile flag is set (decision755). If the aggressive profile flag is set, decision755branches to “Yes” branch758whereupon processing generates and schedules a set of prefetch requests according to an “Aggressive” startup profile, and installs the address, along with an aggressive initial state, in one of the prefetch request queue entries (step765). Processing then resets the state of the aggressive profile flag.

On the other hand, if the aggressive profile flag is not set, indicating that a previous prefetch was not at page boundary, decision755branches to “No” branch756whereupon processing generates and schedules a set of prefetch requests according to a “Normal” startup profile, and installs the address in a prefetch request queue entry (step760).

A determination is made as to whether to continue processing (decision770). If processing should continue, decision770branches to “Yes” branch772, which loops back to process more instructions. This looping continues until processing should terminate, at which point decision770branches to “No” branch778whereupon processing ends at780.

FIG. 8illustrates information handling system801which is a simplified example of a computer system capable of performing the computing operations described herein. Computer system801includes processor800which is coupled to host bus802. A level two (L2) cache memory804is also coupled to host bus802. Host-to-PCI bridge806is coupled to main memory808, includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus810, processor800, L2 cache804, main memory808, and host bus802. Main memory808is coupled to Host-to-PCI bridge806as well as host bus802. Devices used solely by host processor(s)800, such as LAN card830, are coupled to PCI bus810. Service Processor Interface and ISA Access Pass-through812provides an interface between PCI bus810and PCI bus814. In this manner, PCI bus814is insulated from PCI bus810. Devices, such as flash memory818, are coupled to PCI bus814. In one implementation, flash memory818includes BIOS code that incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions.

PCI bus814provides an interface for a variety of devices that are shared by host processor(s)800and Service Processor816including, for example, flash memory818. PCI-to-ISA bridge835provides bus control to handle transfers between PCI bus814and ISA bus840, universal serial bus (USB) functionality845, power management functionality855, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Nonvolatile RAM820is attached to ISA Bus840. Service Processor816includes JTAG and I2C busses822for communication with processor(s)800during initialization steps. JTAG/I2C busses822are also coupled to L2 cache804, Host-to-PCI bridge806, and main memory808providing a communications path between the processor, the Service Processor, the L2 cache, the Host-to-PCI bridge, and the main memory. Service Processor816also has access to system power resources for powering down information handling device801.

Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g., parallel interface862, serial interface864, keyboard interface868, and mouse interface870coupled to ISA bus840. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus840.

In order to attach computer system801to another computer system to copy files over a network, LAN card830is coupled to PCI bus810. Similarly, to connect computer system801to an ISP to connect to the Internet using a telephone line connection, modem875is connected to serial port864and PCI-to-ISA Bridge835.

WhileFIG. 8shows one information handling system that employs processor(s)800, the information handling system may take many forms. For example, information handling system801may take the form of a desktop, server, portable, laptop, notebook, or other form factor computer or data processing system. Information handling system801may also take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.