CN117441144A - Systems and methods for handling asynchronous reset events while maintaining persistent storage state - Google Patents

Abstract

Techniques to handle asynchronous power conversion events while maintaining persistent memory states are described herein. In some embodiments, the system may proxy an asynchronous reset event through system logic that generates an interrupt to invoke a special persistent flush interrupt handler that performs a persistent cache flush prior to invoking hardware power conversion. Additionally or alternatively, the system may include a hardware backup mechanism to ensure that all resets and power conversions requested in hardware are reliably completed within a bounded time window, regardless of whether the persistent cache flush handler is successful.

Description

System and method

Technical field

The present disclosure relates to cache management technology. In particular, this disclosure relates to techniques for refreshing volatile cache state upon a power outage event.

Background technique

Modern server designs often incorporate persistent memory (PMEM), such as data center persistent memory modules (DCPMM) or non-volatile dual in-line memory modules (NVDIMMS), into the memory architecture. Persistent storage offers several advantages over block-based persistent media, including low-latency random access times and the ability to perform remote direct memory access (RDMA) operations directly to persistent storage.

Committing data directly to a persistent memory device is expensive, and servers with persistent memory typically support treating some volatile on-chip state as persistent in order to limit the explicit commits that the software needs to perform The number of operations. If the system can guarantee that the state of the volatile buffer will be flushed to persistent memory on all resets or power transitions (which would otherwise corrupt the contents stored within the volatile buffer), then the program can commit to the volatile buffer. Any data in a persistent buffer is considered persistent. One such method for refreshing volatile buffers is called asynchronous dynamic random access memory refresh (ADR), whereby volatile buffers in the memory controller are included in the persistence domain. Under this approach, the system retains a small amount of energy necessary to keep the system powered after a power outage long enough to flush volatile memory controller buffers out to persistent memory devices.

Another technique called enhanced ADR (eADR) or persistent cache flush (PCF) extends the volatile state that can be handled as persistent to include all processor caches and on-chip buffers. Typically, processor caches are orders of magnitude larger than the volatile memory buffers in the memory controller. Therefore, the system requires significantly more energy to complete the refresh process. Servers that support persistent cache flush must include some form of auxiliary energy storage to power the system during persistent cache flush operations. Some servers include a battery backup unit (BBU) to provide enough energy to complete the flushing of data from the processor cache to persistent storage after a power outage. BBUs can store large amounts of energy; however, they face many challenges, including large footprints, limited ability to supply the high currents required by server systems, thermal constraints, and additional costs.

Asynchronous hardware reset events further complicate the implementation of persistent cache flush operations. Asynchronous hardware resets are typically implemented by directly asserting the reset request pin and may not be detected by the processor or chipset's power sequencing logic. If the system allows an externally initiated reset event to trigger a hardware reset without calling the persistence refresh handler before the reset, the persistent memory state may not be refreshed correctly. If an application relies on persistent cache flushing when the platform hardware does not fully support it, application data may be lost or corrupted during a power outage event.

The approaches described in this section are approaches that could be taken, but are not necessarily approaches that have been previously envisioned or taken. Therefore, unless otherwise indicated, no method described in this section shall be deemed to qualify as prior art solely by virtue of its inclusion in this section.

Description of the drawings

In the figures of the accompanying drawings, embodiments are illustrated by way of example and not limitation. It should be noted that references to "embodiment" or "one embodiment" in this disclosure do not necessarily refer to the same embodiment, and they mean at least one embodiment. In the attached picture:

Figure 1 illustrates a system for performing persistent cache flush operations in accordance with some embodiments.

Figure 2 illustrates an example set of operations for performing persistent cache flush operations to maintain persistent memory state, in accordance with some embodiments.

Figure 3 illustrates an example set of operations for managing persistent cache flush operations in a system with multiple power supplies, in accordance with some embodiments.

Figure 4 illustrates an example system for managing multiple power supplies in accordance with some embodiments.

Figure 5 illustrates an example timing diagram with staggered warning signals from different power supply units in accordance with some embodiments.

Figure 6 illustrates an example set of operations for handling externally initiated asynchronous reset events in accordance with some embodiments.

Figure 7 illustrates an example system for intercepting and handling externally initiated asynchronous reset events in accordance with some embodiments.

Figure 8 illustrates an example set of operations for coordinating persistent memory operating modes in accordance with some embodiments.

Figure 9 shows a block diagram illustrating a computer system in accordance with some embodiments.

Detailed ways

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in another embodiment. In some instances, well-known structures and devices are described with reference to block diagram form in order to avoid unnecessarily obscuring the present invention.

1.General Overview

This article describes techniques for utilizing a system power supply unit (PSU) to provide auxiliary energy to flush volatile system memory to persistent memory following a loss of alternating current (AC) power. In some embodiments, these techniques include implementing an extended hold window long enough to use the energy available in the PSU bulk capacitor to complete a complete refresh of the processor cache and memory controller buffers after a power outage event. Even though the amount of energy available in the PSU is relatively small compared to most BBUs, these techniques can enable volatile system caches to be flushed without the need for a BBU.

Many PSUs contain bulk capacitors that allow the system to handle a temporary 10 millisecond (ms) loss of AC power. An example PSU implementation assumes worst-case output loading and provides a 10ms timer that turns off the power output when the timer expires. This implementation limits the maximum hold window a PSU can achieve to 10ms regardless of system power consumption, which may not be enough time to flush all system caches.

In some embodiments, the PSU is implemented to extend the hold window by an indeterminate time window determined by system power consumption rather than a fixed time window. The voltage on the bulk capacitor within one or more PSUs can be monitored and a notification can be triggered when a programmable power failure warning threshold voltage is detected on the bulk capacitor. The system can configure voltage thresholds to indicate that a specific minimum amount of energy is available in the PSU required to successfully complete a cache flush operation. The PSU may also implement a second voltage threshold associated with the minimum amount of energy required to safely sequence down the system power rails. Because both notifications are based on the amount of available energy in the PSU bulk capacitor, the system can implement a configurable hold window whose duration is determined by the system's power consumption rather than a fixed duration. Therefore, the system can define operating points to minimize energy consumption, rather than being bound by a fixed duration timer.

In some embodiments, system logic may implement an energy counter that estimates the total amount of energy available on all installed PSUs and when the estimated total system energy has reached is associated with the minimum energy required to successfully complete a cache flush operation threshold when an interrupt signal is generated to call the persistence refresh handler. System logic can implement energy counters for each PSU installed in the system. After the PSU has generated a power failure warning signal to the system logic, the system logic may begin decrementing the energy counter associated with the PSU at a rate proportional to the number of active power supplies in the system and the operating mode of the system. System logic can estimate the total energy available by summing each of the per PSU counters. When the total estimated energy drops below a critical threshold, system logic can generate an interrupt signal to invoke the persistence cache flush handler.

In some embodiments, the system is configured to reduce power consumption during the refresh process to minimize the amount of energy required to complete the refresh. The processor, persistent memory device, and supporting circuitry may remain powered. Other system components not participating in the refresh process, such as fans, input/output (I/O) devices, and hard drives, may have power disabled. Power control loops in the system may also include hooks to reduce central processing unit (CPU) power consumption, such as by reducing processor frequency.

To ensure that volatile system resources containing state that are considered persistent are properly flushed to persistent media prior to system resets or power transitions, in some embodiments, a persistence flush is performed before all resets or power transitions Handler that is responsible for pushing out all volatile state to persistent media before reset or power transition. The system can trap accesses to registers used to initiate resets or power state transitions and initiate a persistence cache flush before allowing the trapped write to complete. Capturing accesses to registers allows the system to run the cache flush handler before performing the requested reset or power transition action. Similar mechanisms can be implemented to handle resets and power transitions requested by platform entities external to the host subsystem.

System resets and power transitions can occur not only in response to power outages but also in response to events initiated by external agents. For example, certain system errors may trigger a hardware (HW) initiated system reset. As another example, the user can initiate a thermal reset or force a power outage by holding down a button or flipping a switch. If the system allows an externally initiated reset or power transition event to trigger a hardware reset without calling a refresh handler before the reset, data residing in volatile processor caches or memory buffers may be lost. To ensure that externally initiated system resets or power transitions correctly invoke the persistence refresh handler, the system can proxy these asynchronous events through system logic that generates an interrupt to invoke a special persistence refresh interrupt handler that is Performs a persistent cache flush before invoking the requested HW operation. Additionally or alternatively, the system may include an HW backup mechanism to ensure that all resets and power transitions requested in the HW are completed reliably within a bounded time window, regardless of whether the persistence cache flush handler is successful or not.

The technology described in this article also provides a handshake mechanism and protocol for informing the operating system whether the system hardware supports persistent cache flushing. The system can determine whether the hardware is capable of supporting a full flush of processor caches and volatile memory buffers in the event of a power loss or asynchronous reset. If the hardware is capable, persistent cache flushing can optionally be enabled and advertised to the operating system. Once persistent cache flushing is enabled, the operating system can treat data submitted to the volatile processor cache as persistent. If disabled or unsupported by system hardware, such data may be lost due to power failure or reset events, and the platform may not advertise support for persistent cache flushes to the operating system.

One or more embodiments described in this specification and/or claimed in the claims may not be included in this general summary section.

2. System architecture

In some embodiments, the techniques described herein are implemented on one or more computing devices, such as server devices or other network hosts, that include persistent memory in the memory layout. Although this article provides example computing architectures, these techniques are applicable to a variety of different computing architectures, which may vary depending on the particular implementation. These techniques can be used to (a) determine whether a particular combination of system components is capable of supporting persistent cache flushing, (b) configure the system components to enable persistent cache flushing (if supported), and/or (c) enable In the case of persistent cache flushing, the persistent cache flush handler is executed before a power transition or reset.

Figure 1 illustrates a system for performing persistent cache flush operations in accordance with some embodiments. As shown, Figure 1 includes PSU 102a, PSU 102b, power management subsystem 104, persistent cache flush handler 106, memory subsystem 108, CPU 116, system management module 118, system firmware 120, peripheral components 124, and operating system122. In other embodiments, system 100 may include more or fewer components than shown in FIG. 1 . In some cases, the components shown in Figure 1 may be located locally or remotely from each other.

PSU 102a and PSU 102b convert power into a form that allows the components of system 100 to operate correctly. In some embodiments, PSU 102a and PSU 102b convert AC power into direct current (DC) energy used to power components of system 100. Additionally or alternatively, PSU 102a and PSU 102b may include DC-DC power converters, such as converters that step up or step down the input voltage. PSU 102a and PSU 102b may be electrically coupled to other components of system 100 via one or more power rails, such as +3 Volt (V), +5V, and/or +12V rails. Although two PSUs are illustrated, the system may have only a single PSU or have additional PSUs, depending on the specific implementation.

The power management subsystem 104 controls the delivery of power from the system PSU to the components of the system 100 . In some embodiments, the power management subsystem 104 selectively powers down components during a reset or power outage event to gracefully shut down the system 100 . Additionally or alternatively, power management subsystem 104 may monitor voltage levels across bulk capacitors in PSU 102a and PSU 102b. If the voltage level drops below a programmable threshold, the power management subsystem 104 may assert or deassert the signal to notify other components of the system 100 .

Memory subsystem 108 includes volatile and non-volatile storage areas. In some embodiments, volatile storage areas include processor cache 110 and memory buffer 112 . Processor cache 110 may include caches within CPU 116, such as level 3 (L3) and level 4 (L4) caches, which may be used by CPU 116 to reduce the number of data accesses to main memory. Memory buffer 112 may include registers in CPU 116 and/or a memory controller that provides intermediate storage for data transferred between different regions. For example, a memory controller buffer may provide temporary storage for data being transferred between processor cache 110 and main memory.

Persistent memory 114 includes one or more non-volatile memory devices, such as data center persistent memory modules (DCPMMs) and non-volatile dual in-line memory modules (NVDIMMs). In some embodiments, persistent memory 114 is byte-addressable and resides on a memory bus, thereby providing similar speed and latency to volatile DRAM, which is generally faster than non-resident memory. Peripheral non-volatile storage devices such as hard disks and flash drives are much faster on the bus. Furthermore, persistent memory 114 may be paged and mapped by the operating system 122 in the same manner as volatile DRAM, which is generally not the case with other forms of persistent storage. Persistent memory 114 may serve as main memory within system 100 . In other cases, main memory may include one or more volatile memory modules, such as DRAM.

When a persistent cache flush processor is installed and the platform signaling mechanism is enabled, data stored within the volatile memory area including processor cache 110 and memory buffer 112 may be considered part of the persistent memory state, This is true even in the event of a power outage or other power conversion event. To maintain persistent state, cache flush handler 106 performs and manages cache flush operations in response to detecting trigger events. If persistent cache flush operations are not enabled, a full cache flush may not be performed during a power transition event, and some or all data within the volatile memory area may be lost. Without a persistent cache flush handler, data from memory buffer 112 can be flushed, but processor cache 110 is not flushed, which can reduce the amount of time required to perform a flush operation.

System management module 118 includes software and/or hardware for managing system-level operations. In some embodiments, system management module 118 includes a service processor (SP) and a CPU chipset. System management module 118 may interface with one or more sensors to monitor hardware components. Additionally or alternatively, the system management module 118 may perform other functions, including capturing writes to system registers, generating system management interrupts (SMIs), and monitoring system boot status.

System firmware 120 includes software that provides low-level control of the system hardware. In some embodiments, system firmware 120 includes software, such as basic input/output system (BIOS) firmware, that manages the boot process when the system is powered on or reset. System firmware 120 may also provide runtime services to operating system 122 , such as managing persistent cache flush operations and peripheral components 124 .

Operating system 122 includes software that supports operations including scheduling instruction execution on CPU 116 , providing services to software applications, and controlling access to peripheral components 124 . In some embodiments, system firmware 120 may advertise the ability to include cache content in the persistence domain if supported by system 100 . Operating system 122 may then selectively enable or disable persistent cache flushing. When enabled, operating system 122 may treat data submitted to volatile memory, including processor cache 110 and memory buffer 112, as persistent.

Peripheral components 124 include auxiliary hardware devices such as hard drives, input devices, display devices, and/or other output devices that may be electrically coupled with other components of system 100 . The power consumption of system 100 may vary based in part on connected and active peripheral components 124 . The maximum power load for the worst-case scenario can be calculated by assuming that all hardware components, including peripheral components 124, are operating at full capacity.

3. Persistence cache refresh

3.1 Managing cache flush operations during power outage events

When AC power is lost, it may not be desirable to trigger a cache flush operation immediately because power may be restored quickly. However, there is a risk that if too much time passes without power being restored, the retained energy within PSU 102a and PSU 102b will not be sufficient to perform a full cache flush. If persistent cache flushing is enabled, persistent storage state may become corrupted. To maintain a persistent state, power management subsystem 104 may generate a warning signal when the remaining energy within the bulk capacitors of PSU 102a and PSU 102b drops below a threshold level.

Figure 2 illustrates an example set of operations for performing cache flush operations to maintain persistent memory state, in accordance with some embodiments. One or more operations shown in Figure 2 may be modified, rearranged, or omitted altogether. Accordingly, the specific sequence of operations shown in Figure 2 should not be construed as limiting the scope of one or more embodiments.

Referring to FIG. 2, process 200 includes estimating an amount of ride-through time and hold time based on system load (operation 202). The ride-through time corresponds to an estimated amount of time that system 100 can operate without AC power while leaving sufficient energy to perform cache flushes and sequential power rail shutdowns. The hold time corresponds to the amount of time to perform a full cache flush and sequential power rail shutdown given the system load. The estimate may be calculated based on full system load or reduced system load limited to a maximum value, as further described herein.

In some embodiments, process 200 programs one or more energy thresholds based on the estimated transit time and hold time (operation 204). For example, process 200 may estimate the voltage level in the PSU's bulk capacitor that will guarantee the system 100 an estimated amount of hold time under limited system load to complete cache flush and sequential power rail shutdown operations. The voltage level can then be programmed to the threshold. In other embodiments, the time may be set based on an estimated transit time instead of a voltage/energy based threshold.

In some embodiments, operations 202 and 204 are implemented as separate processes from the remaining operations described herein. For example, operations 202 and 204 may be performed during a boot sequence of system 100, which may calculate the amount of energy required for each operating point and the associated voltage threshold. The calculation may be performed based in part on the detected system components of the boot sequence and estimated power requirements to operate the components during normal operation and/or reduced power operating modes. The boot sequence may then set the programmable voltage threshold of system 100 . In other embodiments, the programmable threshold may be set or modified through user input. For example, a system administrator can set programmable voltage thresholds for each operating point, allowing the system administrator to inject domain knowledge about the system's power requirements.

Referring again to FIG. 2, process 200 includes monitoring for loss of AC power (operation 206). In some embodiments, system 100 includes sensors and/or circuitry that may be embedded in PSU 102a and/or PSU 102b that detect when input AC power is interrupted. In other embodiments, external circuitry and/or sensors may signal system 100 when AC power is lost.

Based on the monitoring circuitry, process 200 may detect the loss of AC power (operation 208). In response, process 200 triggers a notification (operation 210). In some embodiments, notifications are triggered by deasserting the acok signal. Deasserting this signal provides the following warning: Power is no longer stable and the energy reserves within the PSU bulk capacitor have dropped to a critical point where a system shutdown may need to be initiated to preserve the data in a persistent state, marking the beginning of the estimated retention time . In other words, this notification serves to alert the power management subsystem 104 to reserve enough energy in the system PSU to maintain the power rail long enough to perform a full cache flush of the processor cache 110 and memory buffer 112 .

In some embodiments, the early warning mechanism is associated with a fixed time interval before shutdown, in which case the power management subsystem 104 can assume that the system 100 is operating at maximum load and guarantee that the cache flush is completed under the maximum load and Minimum amount of time to shut down power rails in sequence. However, this approach can lead to a conservative implementation where a system shutdown may be initiated earlier than desired, especially if the maximum PSU load is significantly higher than the actual system load during persistence cache flushes. In contrast, a programmable early warning threshold allows the system to trade off energy consumption before asserting a warning signal for crossing versus after asserting a warning signal for hold.

After the notification has been triggered, process 200 continues to power the system components in the first mode of operation (operation 212). When operating in the first mode of operation, system components may be powered using energy in the PSU bulk capacitor. In some embodiments, power may be provided as if the AC were not interrupted. In other embodiments, power saving adjustments may be made within system 100 . For example, processor frequency may be adjusted, display brightness may be dimmed, and/or other power saving actions may be taken. Additionally or alternatively, data may continue to be written to and updated in processor cache 110 and memory buffer 112 .

Process 200 also monitors energy levels within one or more system PSUs based on programmed thresholds (operation 214). In some embodiments, system 100 includes a sensor for monitoring the voltage across a bulk capacitor in the PSU. Since the capacitance value of bulk capacitors is fixed, the voltage in the capacitor can be used as a proxy for the PSU's energy level when AC power is interrupted. In other embodiments, the energy level may be calculated based on the capacitance value of the bulk capacitor and the measured voltage.

Process 200 also determines whether the energy level of one or more PSUs meets a threshold (operation 216). For example, if the measured voltage across one or more bulk capacitors is below a voltage threshold programmed at operation 204, process 200 may determine that the threshold is met. If the threshold is not met, process 200 may continue to monitor the PSU energy level until power is restored or the voltage in the PSU bulk capacitor reaches or drops below the programmable threshold. Once a threshold is met, a warning signal can be asserted to trigger cache flush and power-down sequences.

In some embodiments, process 200 enters the second mode of operation by reducing system load to minimize power consumption (operation 218). During this phase, the power management subsystem 104 may shut down components that are not involved in the cache flush operation. For example, the power management subsystem 104 may power down peripheral components 124, which may include hard drives, fans, displays, Peripheral Component Interconnect Express (PCIe) devices, and/or other peripheral hardware. Additionally or alternatively, the power management subsystem 104 may adjust the clock speed and frequency of the CPU 116 to minimize power consumption.

Process 200 also performs a cache flush (operation 220). During cache flush operations, CPU 116 may write data stored in processor cache 110 and memory buffer 112 to persistent memory 114 to maintain a persistent state of the data. In some embodiments, process 200 may continue to monitor PSU energy levels during this operation. If the PSU energy level drops below the second voltage threshold, process 200 may trigger a power-down sequence to prevent all power rails from being powered down simultaneously, even if the cache flush is not completed. The second voltage threshold can be programmed to a much lower level than the first threshold, leaving enough energy to sequentially turn the power rail off.

Once the cache flush is complete, process 200 powers down remaining system components (operation 224). The process 200 can sequentially shut down the power rails to gracefully shut down the system 100 . The order in which power rails are turned off may vary from system to system.

The process depicted in Figure 2 can maintain persistent memory state without installing a BBU or otherwise relying on power from the BBU. Alternatively, the energy within the bulk capacitors of one or more PSUs may be managed by the power management subsystem 104 to ensure durability. Additionally, the power management subsystem 104 accounts for runtime power loads, which allows for variable ride-through and hold-up times for more efficient and effective use of stored energy.

3.2Manage multiple power supply units

When there are multiple PSUs in the system and one or more of the PSUs lose AC power, the amount of energy in a single PSU may not be sufficient to complete the cache flush operation. However, the aggregate energy across multiple PSUs may be sufficient to complete cache flushes to maintain the persistent state of the data. If multiple PSUs are present, the power management subsystem 104 can monitor the total energy available on all power supplies. When the aggregate voltage level exceeds the threshold, the power management system 104 may issue a power failure warning signal to trigger a cache refresh operation.

In some embodiments, the power management subsystem 104 detects the following events for each PSU being managed:

• Loss of AC power, which can be detected by de-assertion of the acok signal. If this signal is received from one or more PSUs, the power management subsystem 104 may enter a first mode of operation to reduce power during the ride-through window if AC power is restored.

· An indication that the energy or voltage level in the PSU has exceeded a first threshold, which can be detected by the assertion of the vwarn signal. Power management subsystem 104 may combine voltage warning information from all PSUs to determine when to enter the second operating mode, whereby persistent cache flush handler 106 initiates a cache flush operation. The power management system 104 may further reduce power during the second mode of operation, as previously described.

· An indication that the energy or voltage level in the PSU has exceeded the second threshold, which can be detected by the assertion of the pwrok signal. Power management subsystem 104 may combine the pwrok signal information to determine whether to immediately power down the system. A shutdown can be triggered if further drops in PSU energy levels do not leave enough energy to safely shut down the power rails in sequence.

In some embodiments, the power management subsystem 104 maintains a set of per-PSU counters to track estimated energy levels in each PSU in the event of a loss of AC power. The initial value of the per-PSU counter may be hard-coded or programmable to correspond to the amount of energy available in the PSU when vwarn is asserted. When the power management subsystem 104 detects that a PSU has asserted vwarn, it may begin decrementing the associated PSU's energy counter at a rate proportional to the number of active power supplies in the system and the maximum load of each power supply. For example, if there is a single active PSU and the maximum load is 1200 Watts (W), then the counter can be decremented at a rate of 1.2 Joules (J) per millisecond. If there are two active supplies, the load is 600W per supply and the energy counter can be decremented by 600mJ/ms. When using four active power supplies, the energy counter can be decremented by 300mJ/ms. As another example, if the worst case system load is reduced to 1000W, the counter deceleration rate can be modified to 1J/ms for a single power supply, 500mJ/ms for two power supplies, and 250mJ/ms for four power supplies. The counter can be adjusted to provide maximum traversal time while maintaining sufficient energy to sustain persistent cache refreshes against long power outages.

Figure 3 illustrates an example set of operations for managing persistent cache flush operations in a system with multiple power supplies, in accordance with some embodiments. One or more operations shown in Figure 3 may be modified, rearranged, or omitted altogether. Accordingly, the specific sequence of operations shown in Figure 3 should not be construed as limiting the scope of one or more embodiments.

Referring to Figure 3, process 300 detects assertion of one or more vwarn signals from one or more PSUs (operation 302). As mentioned previously, each PSU may be configured to assert a signal when AC power is lost and the energy in the PSU bulk capacitor(s) drops below a threshold, which threshold may be programmable.

In response to detecting the vwarn signal(s), process 300 initiates one or more associated countdown timers (operation 304). In some embodiments, a countdown timer tracks the estimated energy level of each PSU that has asserted the vwarn signal. Process 300 may decrement the counter at a rate proportional to the number of PSUs in the system and the maximum load per power supply. In other embodiments, other mechanisms may be used to track energy levels within the PSU. For example, process 300 may increment a counter instead of decrementing it until a threshold is reached, or use other tracking logic.

Additionally or alternatively, process 300 may cause system 100 to enter a reduced power mode in response to detecting one or more vwarn signals. The reduced power operating mode may be triggered by a single signal or a threshold number of signals, depending on the particular implementation. In other embodiments, process 300 may gradually reduce power with each newly detected signal. For example, process 300 may utilize each new vwarn signal to gradually adjust the CPU frequency and/or initiate or increase other power saving actions as described above.

Process 300 also monitors (a) the aggregate energy level of the combined PSUs based on a countdown timer (or other tracking logic), (b) assertion of additional vwarn signals from other PSUs, and (c) assertion of pwrok signals from the PSUs (operation 306). If an additional vwarn signal is detected, process 300 initiates the associated countdown timer for the PSU(s) asserting the signal (operation 304).

If the aggregate energy level meets the first threshold, process 300 performs a cache flush operation (operation 308). For example, process 300 may determine that the aggregate energy level across all PSUs is equal to or below a minimum threshold. During cache flush operations, CPU 116 may write data stored in processor cache 110 and memory buffer 112 to persistent memory 114 to maintain a persistent state of the data. In some embodiments, process 300 may continue to monitor PSU energy levels during this operation.

If the cache flush operation is completed, or the PSU drops below a second voltage threshold amount that triggers one or more pwrok signals, process 300 sequentially shuts down the power rails (operation 310). When the pwrok signal is detected, process 300 may initiate a power down sequence to prevent all power rails from being powered down simultaneously, even if the cache flush is not completed. The second voltage threshold can be programmed to a much lower level than the first threshold, leaving enough energy to sequentially turn the power rail off.

Figure 4 illustrates an example system 400 for managing multiple power supplies in accordance with some embodiments. System 400 includes PSUs 402 and 404. However, the number of PSUs may vary depending on the specific implementation. Each PSU may include one or more bulk capacitors, such as capacitor 406, which store electrostatic energy obtained from the connected AC power network. Capacitor-based storage allows PSUs to be implemented with a smaller footprint than BBUs and provide faster charge and discharge rates. PSUs 402 and 404 may be connected to the same AC power network or different AC power networks, depending on the particular implementation. If connected to a different AC power network, it is possible for one PSU to lose AC power while the other PSU continues to be powered by a different AC network. In this scenario, each PSU may provide a separate acok signal to the power management subsystem 408 (not shown). When AC power is lost, these signals can be deasserted independently by each PSU to signal which PSU is losing power. In other cases, de-assertion of the acok signal may signal that a group of PSUs or all PSUs have lost AC power.

In some embodiments, each PSU asserts the vwarn signal when the energy in the bulk capacitor (eg, bulk capacitor 406) reaches a threshold. Therefore, the vwarn signal notifies the power management subsystem 408 that the available energy of the associated PSU is at the first threshold level. The power management subsystem 408 maintains separate energy counters for each PSU, and these counters are triggered when the associated PSU asserts the vwarn signal. For example, when PSU 402 asserts the vwarn signal, power management subsystem 408 may decrement energy counter 410 at a rate proportional to the number of PSUs in the system and the maximum load per power supply. Energy counter 412 is managed independently of energy counter 410 (the vwarn signal from a PSU does not trigger counting of unrelated counters for other PSUs) and is decremented in response to PSU 404 asserting the vwarn signal. The power management subsystem 408 includes a summer 414 that sums the estimated energy counts of the PSUs together to calculate an aggregate energy counter 416 .

In some embodiments, the power management subsystem monitors the aggregate energy counter 416 to determine whether the aggregate energy across all PSUs has reached or fallen below a system threshold, which may be programmable and vary depending on the particular implementation. If the threshold is reached, then the power management subsystem 408 asserts the SMI signal to stop the current task being executed by the CPU/chipset 422 in preparation for a persistent cache flush and reset. In response to the SMI, persistence cache flush handler 424 may initiate the previously described persistence cache flush operation.

Figure 5 illustrates an example timing diagram 500 with interleaved warning signals from different power supply units in accordance with some embodiments. The upper portion of graph 500 depicts the timing of a power failure, while the lower portion of graph 500 depicts the potential power reduction that system 100 can achieve in response to an impending power failure. Diagram 500 assumes worst case behavior where the system operates at maximum load until a power failure cache flush is triggered. When a power-failure cache flush is triggered, system power consumption is reduced, minimizing the load on completing the flush operation.

The variables of graph 500 can be defined as follows:

·t _{psu0_v1warn} – The time the first PSU asserted v1warn

·t _{psu1_v1warn} – The time the second PSU asserted v1warn

· _{tflush_start} – the time when the power management subsystem 104 initiates the power fault refresh operation

·t _{psu1_pwrok} – The time when the second PSU deasserts pwrok and system 100 begins the power down sequence

·T _{v1warn_delay} – time delay between t _{psu0_v1warn} and t _{psu1_v1warn}

·T _{v1warn_debounce} – the time delay between t _{psu1_v1warn} and t _{flush_start} ,

T _v1warn – the time to utilize all E _v1warn energy in the power supply when at maximum load

·P _max – maximum system load

P _throttle – System load after first PSU asserts v1warn

·P _debounce – System load after all PSUs have asserted v1warn

· _Pflush – system load when power failure flush operation is triggered

E _v1warn - The usable energy available in the PSU after v1warn is asserted but before pwrok is deasserted

· E _pwrok – the usable energy available in the PSU after pwrok is deasserted and before the main power rail is lost

·E _{psu0_reserve} – The available energy remaining in the first PSU to assert v1warn after the second PSU asserts v1warn at t _{psu1_v1warn}

· E _reserve – The total usable energy remaining in all PSUs after v1warn is asserted on all PSUs but before deassertion of pwrok on the last PSU.

·E _{v1warn_delay} – The energy consumed by system 100 during t _{v1warn_delay}

_Eflush – the energy required to successfully complete a power failure flush operation

·N – Number of active PSUs providing power to the system

Referring to Figure 5, when the first PSU asserts v1warn at t _{psu0_v1warn} , the PSU has (E _v1warn + E _pwrok ) available energy before the power shuts down the associated power rail and stops providing power to the system. There are N active PSUs, and the system load is divided among all active PSUs in the system. At some later point in time, the second PSU asserts v1warn at t _{psu1_v1warn} . The amount of energy consumed during the time period between t _{psu0_v1warn} and t _{psu1_v1warn} is expressed as E _{v1warn_delay} .

System 100 draws power from all N active PSUs during the period after the first power supply has asserted v1warn but before the second power supply has asserted v1warn. The maximum energy consumed by the first PSU after asserting v1warn is ((E _v1warn +E _pwrok ). The energy remaining in the first PSU when the second CPU asserts v1warn is denoted as E _psu0reserve .

If T _{v1warn_delay} is small, the second PSU deasserts pwrok before the system has consumed all energy from the first power supply. In the worst case scenario, when both power supplies simultaneously assert v1warn and each assert v1warn, both power supplies will also simultaneously deassert pwrok. In these cases, if the system shuts down when all power supplies deassert pwrok, then any E _pwrok energy may not be used in the first power supply. To allow for this possibility, the system 100 may be configured to assume that _Epwrok energy is not available in the first power source.

To utilize all energy from both power supplies, the system 100 may be configured so that power-down refresh does not begin immediately when the second PSU asserts v1warn. Alternatively, system 100 may delay refresh triggering until the amount of energy reserved in all active PSUs equals the amount required to complete the refresh. System 100 may also be configured to ensure E _reserve ≥ E _flush to reserve sufficient energy to complete the cache flush operation.

If both PSUs assert v1warn simultaneously, then T _{v1warn_delay} =0 and T _{v1warn_debounce} =T _v1warn . If the PSU asserts v1warn far apart, then T _{v1warn_debounce} = 0, and once the second PSU asserts v1warn, a power failure refresh can be triggered. The power management subsystem 104 may program the energy/voltage thresholds accordingly.

4.Manage externally initiated asynchronous reset events

Power outage events are not the only reason for system shutdown or reset. In some cases, system errors or user actions may trigger a system shutdown or reset. For these externally initiated asynchronous events, monitoring power loss may not be sufficient to maintain persistent memory state because A/C power may be relatively constant. Asynchronous hardware reset is typically implemented by directly asserting the reset request pin, which initiates the reset in the HW, and may not provide any ability to call the software cache flush handler before the reset. In some embodiments, to prevent data loss, board logic is configured to generate an SMI signal to initiate a cache flush when an externally initiated reset request is detected.

Figure 6 illustrates an example set of operations for handling externally initiated asynchronous reset events in accordance with some embodiments. One or more operations shown in Figure 6 may be modified, rearranged, or omitted altogether. Accordingly, the specific sequence of operations illustrated in Figure 6 should not be construed as limiting the scope of one or more embodiments.

Referring to Figure 6, process 600 intercepts assertion of the HW reset request signal (operation 602). In some embodiments, platform-initiated reset requests, including those initiated by system management module 118 , are proxied through power management subsystem 104 . This allows the system 100 to run the persistent cache flush handler 106 before performing the requested reset or power transition action.

In some embodiments, process 600 determines whether persistent cache flushing is enabled (operation 604). As described further below, system firmware (or other system logic) may selectively enable or disable persistent cache flushing to configure whether data in processor cache 110 is included in persistent memory state.

If persistent cache flushing is not enabled, process 600 routes the request to the reset pin (operation 606). In some embodiments, power management subsystem 104 routes requests to the system chipset. The chipset can initiate the HW reset sequence.

If persistent cache flushing is enabled, process 600 routes the request to system management module 118 (operation 608). In this case, the reset pin is not asserted immediately in response to a platform- or user-initiated reset to allow time for the software-based cache flush handler to be called.

In some embodiments, process 600 generates an SMI signal to place system 100 into system management mode (operation 610). The SMI signal may be asserted by the system management module 118 , which may use special signaling lines tied directly to the CPU 116 . This signal may cause system firmware 120 (eg, BIOS) to pause the current task being executed by CPU 116 in preparation for cache flushing and reset.

In some embodiments, if persistent cache flushing is enabled, system firmware 120 (eg, BIOS) configures a general-purpose input/output (GPIO) pin within system management module 118 as a trigger for SMI. The GPIO pins may be used to signal system firmware 120 when a cache flush and subsequent warm reset is to be performed. This GPIO may be different from the one used to signal the chipset of an impending power failure, to convey that the persistent cache flush handler should be terminated by requesting a warm reset rather than a power outage.

Process 600 next performs a cache flush operation (operation 612). In response to the SMI signal, system firmware 120 may invoke cache flush handler 106 to manage cache flush operations, as previously described. Accordingly, data is transferred from volatile memory, such as processor cache 110 and memory buffer 112, to persistent memory 114, thereby maintaining a persistent state.

Process 600 further determines whether the refresh is complete (operation 614). Persistent cache flush handler 106 may assert a signal or otherwise provide notification when data in processor cache 110 and memory buffer 112 has been written to persistent memory 114 .

Once the cache flush is complete, process 600 generates a reset request (operation 622). For example, the persistent cache flush processor 106 may be initiated by writing a specific value to a specific IO port/register of the PCH (e.g., 0x06 to port CF9) or by requesting the system logic from the chipset to assert the HW reset request signal. System reset.

If the refresh is not completed, process 600 may determine whether the timeout has been reached (operation 616). For example, process 600 may allow one second or another threshold period of time (which may be configured by system 100) for the refresh operation to complete. In some cases, the system state associated with the reset event may prevent the refresh from completing. Implementing a timeout prevents the system 100 from entering a state where a warm reset cannot be performed.

If the timeout is reached, then process 600 generates a reset request signal directly to the chipset (operation 618). The reset request in operation 622 may also be a direct reset request to the chipset or may be a software-based request. Therefore, the mechanism for resetting the system may vary based on whether the refresh completed successfully.

In response to the reset signal, system 100 is then reset (operation 420). A reset in this scenario can cause the system 100 to shut down or restart.

Figure 7 illustrates an example system 700 for intercepting and processing externally initiated asynchronous reset events in accordance with some embodiments. System 700 includes a system management module 702, which may be implemented in programmable hardware such as a field programmable gate array (FPGA), or through other hardware components (or a combination of hardware and software) as described further below. to fulfill. The system management module 702 acts as a proxy, intercepting the assertion of a hardware request signal, which may be triggered by a user pressing a reset button or a reset request asserted by a board management controller (BMC) or debug header. .

System management module 702 includes logic gate 704 that routes the asserted reset request signal to demultiplexer 706 . The select lines coupled to demultiplexer 706 are set based on whether persistent cache flushing is enabled or disabled. A "0" or low voltage state represents a memory operating mode in which persistence cache flushing is disabled and data in processor cache 110 and memory buffer 112 are not managed as part of the persistence domain. A "1" or high voltage state represents a mode of persistence cache operation in which persistence cache flushing is enabled and data in processor cache 110 and memory buffer 112 are part of the persistence domain. However, depending on the specific implementation, the values on the selection lines may be swapped.

When persistent cache flushing is disabled, the system management module 702 then asserts a request reset interrupt signal to a pin electrically coupled to the CPU/chipset 712 . In response, reset control logic 714 on the CPU/chipset 712 suspends the current task being executed and initiates a hardware reset, which may include sending a signal to reset the finite state machine (FSM) 710 . Resetting the FSM 710 can sequentially shut down the power rails in a specific order to avoid damage to hardware components. As mentioned previously, the order in which power rails are shut down can vary depending on the system architecture.

When persistent cache flushing is enabled, the system management module 702 asserts SMI using a special signaling line tied directly to another pin on the CPU/chipset 712 . This signaling line is different from the previously described line used to perform a HW reset when persistent cache flushing is not enabled. In response to detecting the SMI, the CPU/chipset 712 sends a software-based request to the power failure flush handler 716 to initiate a persistent cache flush.

In response to the request, persistence cache flush handler 716 initiates a persistence cache flush operation to transfer data from the processor cache and memory buffers to the persistent storage medium. If the cache flush completes successfully, the power failure flush handler 716 sends a software reset request to the reset control logic 714, which can trigger the power down sequence as previously described.

When persistent cache flushing is enabled, system management module 702 further initializes timer 708. Timer 708 may decrement or increment until canceled or a timeout value is reached. Counting may be canceled in response to detection of the assertion of a signal on the input pin that resets the FSM 710. This signal indicates that the power failure flush handler 716 successfully flushed the processor cache and memory buffers to the persistent storage medium and that a reset sequence has been initiated. If the timeout value is reached before the timer is canceled, the system management module 702 can directly assert the rst_req_in pin on the CPU/chipset 712 to trigger a HW reset.

5. Coordinate persistent cache flush state between system components

System boot firmware can expose persistent cache flush support via user-configurable options. However, boot firmware can be deployed on a wide variety of hardware platforms, and presenting this option may not imply that the specific platform hardware is capable of supporting persistent cache flushing. Whether a platform is able to support persistent cache flushes may depend on hardware configuration, the presence and/or health of the energy storage module, and the capabilities of the underlying hardware components. In some embodiments, components of system 100 participate in a handshake to (a) determine whether the hardware has sufficient capabilities to support persistent cache flush; (b) selectively enable/disable persistent cache flush; (c) when When persistent cache flush is enabled, configure system components to support persistent cache flush; and (d) communicate with the operating system whether persistent cache flush has been successfully enabled.

Figure 8 illustrates an example set of operations for coordinating persistent memory operating modes in accordance with some embodiments. One or more operations shown in Figure 8 may be modified, rearranged, or omitted altogether. Accordingly, the specific sequence of operations shown in Figure 8 should not be construed as limiting the scope of one or more embodiments.

Referring to Figure 8, process 800 initiates a boot sequence (operation 802). In some embodiments, the boot sequence loads system firmware 120, which may include BIOS firmware. The firmware can be configured to expose user-configurable options for persistent cache flushing. For example, the firmware may present a prompt to the user whether the user wants to enable persistent cache flushing, or the user may navigate a user interface, such as a BIOS setup utility screen.

In some embodiments, the user interface exposes multiple settings of the "Durability Domain" settings option to configure whether the platform will operate in ADR mode or persistence cache flush mode. For example, the user interface may expose options for selecting "Memory Controller" settings or "CPU Cache Hierarchy" settings. In the Memory Controller settings, ADR is enabled but persistent cache flushing is disabled. When this setting is selected, memory buffer 112 is flushed during a power outage event, but flush operations are not applied to processor cache 110 . In some embodiments, system hardware may be configured with this setting by default.

In the "CPU Cache Hierarchy" settings, persistent cache flushing is enabled. Therefore, if this option is selected, data in memory buffer 112 and processor cache 110 are flushed on a power outage event, provided the platform hardware supports persistent cache flush operations.

Additionally or alternatively, other settings may be supported. For example, you can select a "Standard Domain" setting, in which cached data is not flushed in the event of a power failure. The user can select preferred settings via the user interface, as described above. If the user does not select settings, system firmware 120 may select default settings, which may vary depending on the particular implementation.

In some embodiments, system firmware 120 checks to determine whether persistent caching mode has been selected by the user or selected by default (operation 804). Even if this option is selected, the platform hardware may not support persistent cache flush operations in some cases. In addition, system hardware may evolve over time as components are added, removed, aged, and/or fail.

If persistent cache mode has not been selected, system firmware 120 continues the boot sequence without advertising support for persistent cache mode (operation 822). The boot sequence may include initializing hardware components, loading the operating system, and/or processing system boot files that have not yet been processed. The boot sequence can continue without performing the hardware capability checks described further below.

If persistent cache mode has been selected, system firmware 120 sends a request to system management module 118 to determine whether system 100 is capable of supporting persistent cache flush operations (operation 806).

In response to the request, system management module 118 evaluates the hardware capabilities of system 100 (operation 808). In some embodiments, the system management module 118 may participate in a handshake with one or more hardware components to determine settings, configuration, and/or other information indicating whether persistent cache flushing is supported. For example, during a boot sequence, a connected hardware component may include firmware that provides the system firmware with a list of features supported by the component. System management module 118 may scan the provided feature list and/or other information to determine whether the feature is compatible with persistent cache flushing.

In some embodiments, evaluating the hardware capabilities of system 100 includes determining whether PSU 102a and/or PSU 102b supports generating warning signals and configuring a programmable vwarn threshold. For example, system management module 118 may determine whether PSU 402 includes a pin for asserting the vwarn signal. If the PSU does not have these capabilities, system management module 118 may determine that the platform hardware does not support persistent cache flush operations.

Additionally or alternatively, the system management module 118 may determine whether the power management subsystem 104 includes logic to detect vwarn signals, monitor aggregate energy levels across multiple PSUs, and/or trigger an interrupt when system-wide energy levels fall below a threshold. . If the power management subsystem 104 does not have these capabilities, the system management module 118 may determine that the platform hardware does not support persistent cache flush operations.

Additionally or alternatively, system management module 118 may evaluate other hardware capabilities. For example, system management module 118 may evaluate system 100 to determine whether the system supports intercepting reset signals and configuring GPIO pins to handle asynchronous reset events. As another example, system management module 118 may evaluate CPU 116 to determine whether it includes a special signaling line for invoking a persistent cache flush handler.

Additionally or alternatively, the system management module 118 may determine whether any BBUs that support persistent cache flush operations have been installed. If the BBU has been installed, the system management module 118 may determine that persistent cache flushing is supported even if the PSU architecture does not provide support. On the other hand, if the BBU is not installed and the PSU and/or power management subsystem does not support persistent cache flush operations, the system management module 118 may determine that persistent cache flushing is not supported.

Additionally or alternatively, system management module 118 may evaluate other hardware capabilities. For example, system management module 118 may evaluate the capacity of auxiliary energy storage devices installed in the platform, such as BBUs, and determine whether the devices provide sufficient energy to power system components that are active during the refresh process. Additionally or alternatively, the system management module 118 may evaluate the health of the battery, such as by measuring battery impedance, to determine whether the platform hardware supports persistent cache flushing.

Based on this evaluation, system management module 118 returns a response to system firmware 120 indicating whether the platform is capable of supporting persistent cache flushing (operation 810 ). If supported, the response may grant system firmware 120 permission to enable persistent cache flushing. Otherwise, system management module 118 denies system firmware 120 the ability to enable persistent cache flushing.

When the response is received, system firmware 120 determines whether system 100 supports persistent cache flushing (operation 812).

If the platform hardware does not support persistent cache flushing, system firmware 120 continues the boot sequence without advertising support for persistent cache flushing to operating system 122 (operation 822). When persistent cache flushing is not advertised and enabled, the operating system 122 may prevent applications from attempting to treat the processor cache as persistent in the system 100 .

If persistent cache flushing is supported, system firmware 120 and/or system management module 118 configure the system components to support persistent cache flushing operations (operation 814). For example, system firmware 120 may establish GPIO pins, initialize per-PSU timers, configure PSUs, and otherwise configure system hardware/software to perform cache flush operations, as previously described.

System firmware 120 and/or system management module 118 then advertise support for persistent cache flushing to operating system 122 (operation 816). In some embodiments, system firmware 120 may provide a list of supported features and/or configuration settings to operating system 122 . The list can include entries indicating that persistent cache flushing is supported and enabled. However, the manner in which support is announced may vary depending on the specific implementation.

Based on the notification, operating system 122 detects whether persistent cache mode is supported (operation 818). For example, operating system 122 may scan a list of supported features during the boot sequence to determine whether system firmware or system management module 118 is advertising support for persistent cache flushing.

If the platform hardware enables and supports persistent cache mode, operating system 122 advertises persistent cache mode to one or more applications (operation 820). In some embodiments, the application may query the operating system 122 to determine whether persistent cache mode is available and supported. The operating system 122 may provide a response to indicate whether the application can rely on the persistent cache. Applications can implement different logic depending on whether persistent caching is enabled and supported. For example, if enabled, database applications can treat reads and writes as committed without having to implement complex software-based checks, which can simplify application code and provide more efficient execution of reads and writes.

As system components evolve, process 800 may be repeated to determine whether support for persistent cache mode has changed. A change in hardware, such as the installation of a BBU or a PSU upgrade, may cause the system 100 to advertise support for persistent cache flushes that it did not previously support. In other cases, the advertisement may be removed if a component such as the BBU is removed or fails.

6. Hardware implementation

According to one embodiment, the techniques described herein are implemented by one or more special purpose computing devices. Special purpose computing devices may be hardwired to perform the present technology, or may include digital electronic devices permanently programmed to perform the present technology, such as one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) ) or network processing unit (NPU), or may include one or more general-purpose hardware processors programmed to perform the technology according to program instructions in firmware, memory, other storage devices, or a combination. This specialized computing device can also combine custom hardwired logic, ASIC, FPGA or NPU with custom programming to implement the technology. A special purpose computing device may be a desktop computer system, a portable computer system, a handheld device, a networked device, or any other device that incorporates hardwiring and/or program logic to implement technology.

For example, FIG. 9 is a block diagram illustrating a computer system 900 on which embodiments of the invention may be implemented. Computer system 900 includes a bus 902 or other communication mechanism for communicating information and a hardware processor 904 coupled with bus 902 for processing information. Hardware processor 904 may be, for example, a general-purpose microprocessor.

Computer system 900 also includes main memory 906 , such as random access memory (RAM) or other dynamic storage device, coupled to bus 902 for storing information and instructions to be executed by processor 904 . Main memory 906 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 904. Such instructions, when stored in a non-transitory storage medium accessible to processor 904, cause computer system 900 to become a special purpose machine customized to perform the operations specified in the instructions.

Computer system 900 also includes a read-only memory (ROM) 908 or other static storage device coupled to bus 902 for storing static information and instructions for processor 904 . A storage device 910, such as a magnetic or optical disk, is provided and coupled to bus 902 for storing information and instructions.

Computer system 900 may be coupled via bus 902 to a display 912 for displaying information to a computer user, such as a cathode ray tube (CRT) or light emitting diode (LED) monitor. Input device 914 , which may include alphanumeric and other keys, is coupled to bus 902 for communicating information and command selections to processor 904 . Another type of user input device is a cursor control 916 , such as a mouse, trackball, touch screen, or cursor direction keys, for communicating directional information and command selections to the processor 904 and for controlling cursor movement on the display 912 . Input device 914 typically has two degrees of freedom in two axes, a first axis (eg, x) and a second axis (eg, y), which allows the device to specify a position in a plane.

Computer system 900 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and/or program logic. and/or program logic combined with the computer system to make the computer system 900 a special purpose machine or to program the computer system 900 as a special purpose machine. According to one embodiment, the techniques herein are performed by computer system 900 in response to processor 904 executing one or more sequences of one or more instructions contained in main memory 906 . These instructions may be read into main memory 906 from another storage medium, such as storage device 910 . Execution of the sequences of instructions contained in main memory 906 causes processor 904 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

The term "storage medium" as used herein refers to any non-transitory medium storing data and/or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and/or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 910 . Volatile media includes dynamic memory, such as main memory 906 . Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid state drives, magnetic tape or any other magnetic data storage media, CD-ROM, any other optical data storage media, any physical media with a hole pattern, RAM, PROM and EPROM , FLASH-EPROM, NVRAM, any other memory chip or cartridge, Content Addressable Memory (CAM) and Tri-State Content Addressable Memory (TCAM).

Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media include coaxial cable, copper wire, and fiber optics, including the wires that include bus 902. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 904 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of the remote computer. The remote computer can load the instructions into its dynamic memory and use a modem to send the instructions over a network line such as a telephone line, fiber optic cable, or coaxial cable. A modem local to computer system 900 can receive data on the network line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector can receive the data carried in the infrared signal, and appropriate circuitry can place the data on bus 902. Bus 902 carries the data to main memory 906, from which processor 904 retrieves and executes the instructions. Instructions received by main memory 906 may optionally be stored on storage device 910 before or after execution by processor 904 .

Computer system 900 also includes a communications interface 918 coupled to bus 902 . Communication interface 918 provides bidirectional data communications coupled to network link 920 , which connects to local network 922 . For example, communications interface 918 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communications connection to a corresponding type of telephone line. As another example, communications interface 918 may be a LAN card that provides a data communications connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communications interface 918 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

Network link 920 typically provides data communications to other data devices through one or more networks. For example, network link 920 may provide a connection to a host computer 924 through a local network 922 or to data equipment operated by an Internet service provider (ISP) 926. The ISP 926 in turn provides data communications services over the global packet data communications network now commonly referred to as the "Internet" 928 . Both local network 922 and Internet 928 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through the various networks and signals on network link 920 and through communication interface 918 are example forms of transmission media that carry digital data to and from computer system 900 .

Computer system 900 may send messages and receive data, including program code, over network(s), network link 920, and communication interface 918. In the Internet example, server 930 may transmit the requested code for the application over the Internet 928, ISP 926, local network 922, and communication interface 918.

The received code may be executed by processor 904 as it is received, and/or stored in storage device 910 or other non-volatile storage for later execution.

7. Other matters; expansion

Embodiments are directed to a system having one or more devices including a hardware processor and configured to perform any of the operations described herein and/or as recited in any of the following claims.

In embodiments, a non-transitory computer-readable storage medium includes instructions that, when executed by one or more hardware processors, cause any of the operations described herein and/or recited in any of the claims to be performed.

Any combination of the features and functionality described herein may be used in accordance with one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indication of the scope of the invention, and what applicants intend to be the scope of the invention, is the literal and equivalent scope of the claims in the specific form of a set of claims arising from this application, including any subsequent corrections.

Claims (21)

1. A method, comprising:

identifying a request to initiate a reset or power conversion in a computing system;

responsive to identifying the request, determining whether a first mode is enabled in the computing system for performing a persistent cache refresh;

in response to determining to enable the first mode, generating an interrupt that triggers a persistent cache refresh operation; and

the reset or power conversion is delayed until the persistent cache refresh operation has completed or a timeout has expired.

2. The method of claim 1, further comprising brokering, by system logic, a source of a power conversion event, the system logic configured to (a) when in the first mode, generate an interrupt that triggers the persistent cache flush operation and delay the power conversion event; and (b) when operating in the second mode, directly routing a request to perform power conversion to a chipset of the computing system.

3. The method of claim 1, wherein the request to initiate the reset or power conversion is detected based on an error in the computing system.

4. The method of claim 1, wherein the request to initiate the reset or power conversion is detected based on a user interaction with hardware in the computing system.

5. The method of claim 1, wherein the request to initiate the reset or power conversion is detected based on a user interaction with a board management controller in the computing system.

6. The method of claim 1, further comprising: configuring a general purpose input/output pin of a hardware component within the computing system in response to determining to enable the first mode, wherein the hardware component triggers the persistent cache refresh operation when the interrupt is asserted on the general purpose input/output pin.

7. The method of claim 1, wherein the persistent cache refresh operation transfers data in a volatile processor cache to persistent memory.

8. The method of claim 1, wherein resetting the computing system after the persistent cache refresh operation has completed comprises writing a value to a register that triggers a warm reset of the computing system.

9. The method of claim 1, wherein initiating power conversion of the computing system after the persistent cache refresh operation has completed comprises writing a value to a register that triggers power conversion of the computing system.

10. The method of claim 1, wherein resetting the computing system after the persistent cache refresh operation has completed or a timeout has expired comprises asserting a reset request signal to a chipset of the computing system.

11. The method of claim 1, wherein initiating power conversion of the computing system after the persistent cache refresh operation has completed or a timeout has expired comprises asserting a power state conversion request signal to a chipset of the computing system.

12. The method of claim 1, wherein a reset or power conversion request is routed to an interrupt signal that triggers an interrupt handler that flushes a processor cache when the first mode is enabled.

13. The method of claim 1, wherein when the first mode is disabled, the reset request is routed to a reset pin in the system without flushing the processor cache.

14. A system, comprising:

a hardware processor;

a chipset coupled to the hardware processor, comprising (a) a first pin for receiving an interrupt signal that triggers a persistent cache refresh operation, and (b) a second pin for receiving a reset request signal;

wherein the chipset pauses task execution on the hardware processor and invokes a persistent cache flush handler in response to detecting the interrupt signal on the first pin;

wherein the chipset pauses task execution on the hardware processor and initiates a reset in response to detecting a reset request signal on the second pin without invoking the persistent cache refresh handler.

15. The system of claim 14, further comprising system logic to act as a proxy for a source of a reset or power conversion event and electrically coupled to the first pin and the second pin, wherein the system logic (a) when in the first mode, generates an interrupt signal to invoke the persistent cache flush handler and delays the reset or power conversion event; and (b) when operating in the second mode, routing a request to perform a reset or power conversion directly to a second pin of the chipset.

16. The system of claim 14, wherein the system logic comprises a timer that is started when the interrupt signal is generated; wherein the system logic is configured to send a reset request signal to the first pin in response to detecting that the timer has expired, and cancel the timer if the persistent cache refresh operation is completed before the timer has expired.

17. The system of claim 14, wherein the system logic intercepts requests from hardware components interacting with a user, a debug header, and a board management controller to initiate a reset or power conversion event.

18. The system of claim 14, wherein the first pin is a general purpose input/output pin; wherein the chipset is configured to detect an interrupt signal and invoke a persistent cache refresh handler in response to detecting that a persistent cache refresh is enabled on the system.

19. The system of claim 14, wherein the hardware processor comprises a set of volatile processor caches; wherein the persistent cache flush handler transfers data in the volatile processor cache to the persistent memory when invoked.

20. A system comprising means for performing the operations of any one of claims 1-13.

21. A non-transitory computer-readable medium comprising instructions that, when executed by a hardware processor, cause performance of the operations of any one of claims 1-13.