Shared Persistent Memory for Zero-Time Hardware State Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing hardware recovery processes often result in the loss of hardware state information or fail to reflect the latest system recovery state, particularly during device failures or updates.
Innovation Solution
A zero-time hardware recovery process utilizing a persistent memory shared between applications, where a primary application manages communication ports and listens for recovery attempts, while a secondary application writes and retrieves hardware state information to/from this memory, enabling rapid recovery from crashes or updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If hardware state information is stored in volatile memory during application execution, then the system operates with fast access speed, but the information is lost upon device failure or process termination
Solution Approach 1:
The patent applies preliminary action by continuously writing hardware state information to persistent storage during normal application execution, so that when a failure occurs, the information is already prepared and available for immediate recovery, eliminating the need for time-consuming post-failure data collection
Solution Approach 2:
The patent introduces a communication port and message passing mechanism as an intermediary between the application process and hardware recovery system. This intermediary captures hardware state information and transmits it to a recovery process, enabling reliable state preservation without requiring direct access to hardware during failure events
2Reliability
If hardware state information is recovered after a failure event, then the system can resume operation, but the recovered information may not reflect the latest system state
Solution Approach 1:
The patent implements feedback by continuously monitoring hardware state changes during application execution and immediately writing updated state information to persistent storage. This continuous feedback loop ensures that the most current system state is preserved, so when recovery occurs, the latest accurate information is available
Solution Approach 2:
The patent maintains continuity of useful action by continuously capturing and storing hardware state information throughout the application's lifecycle, rather than only at discrete checkpoints. This continuous recording ensures that no critical state changes are missed, providing complete and accurate recovery data
3Productivity
If a persistent memory is shared between applications for storing execution data and hardware state information, then recovery speed is improved, but memory management complexity increases
Solution Approach 1:
The patent applies universality by creating a communication port that serves multiple functions: it manages persistent memory allocation, captures hardware state information, transmits data to recovery processes, and handles message passing. This multi-functional approach consolidates memory management tasks into a single unified mechanism, reducing overall system complexity despite the shared memory architecture
Data Source
AI summary
Embodiments of the present disclosure are directed to a zero-time hardware recovery process. The recovery process utilizes a persistent memory shared between applications and in which the applications write execution data and hardware state information. This memory can be a file, a network database, another network resource, etc. Generally speaking, a primary application creates and manages communication ports which are used as a communication channel to the hardware/firmware and which can be shared between the applications. The primary application also listens for process recovery attempts. A secondary application writes execution data and hardware state information to the persistent memory. Upon a recovery of the second process, the execution data and hardware state information is received from the shared persistent memory. The recovery can be performed in response to a crash or a version update.