JP2005107573A - Computer system which can restore execution state - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To restore the states of main storage, CPU and a peripheral device while maintaining consistency between them even if the system faces sudden power supply shutdown on the premise that a main storage is non-volatile. <P>SOLUTION: The computer system is composed of elements such as: a kernel (OS) 210; device drivers 220, 230 and 240 which correspond to respective peripheral devices 142 to 144 and serve as the interfaces between the kernel and the devices; and application programs 262, 264 and 266 executed on the OS210 in a user level. By considering that the device drivers 220, 230 and 240 are the elements where dependence on the devices 142, 143 and 144 occurs, consistency is maintained between the individual devices and the device drivers. Thus, the system can be restored from sudden power supply shutdown. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to execution state restoration of a computer system using a nonvolatile memory as a main memory.

Building a system that can restore its execution state even when sudden power-off is faced greatly improves the reliability and convenience of widely used computer systems. At present, there are many attempts to supply power to computer systems in various forms called “ubiquitous power supplies”. These power supplies are basically unstable and power supply to the system must be intermittent. A computer system that operates in such an environment is required to have an ability to immediately recover the execution state of the system when the power is turned off. If the OS or application needs to be restarted every time the power is lost, the convenience is greatly impaired.
In order to restore the running state when the system faces a sudden power off, the state of the entire system before the power is turned off is saved and must be recoverable when the system is restarted (recovered) is there. In addition, the restored state needs to be consistent throughout the system. The execution state of the system includes a state held by a peripheral device together with the CPU and main memory. For the purpose of improving fault tolerance, many studies have been conducted to restore the system state against failures in the fail-stop model (see Non-Patent Documents 1 to 3). However, it mainly targets the state of the CPU and main memory, and the state of peripheral devices connected to the system has not been considered much. For example, libckpt (see Non-Patent Document 4) only restores information on open file descriptors and gazing points on files, and does not consider the status of the device itself.

  System power management specifications such as APM (see Non-Patent Document 5) and ACPI (see Non-Patent Document 6) realize system execution state restoration (suspend / resume and hibernation) including the state of peripheral devices. In these implementations, the system state including peripheral devices is saved / restored when a power supply state transition request is notified. However, since it is assumed that the state storage process is performed while sufficient power is left, the case where power is suddenly lost or the power required for the storage process is not sufficiently left. Cannot handle the case. Furthermore, most of the technologies up to now assume that the contents of the main memory are lost when the power is turned off, and it is necessary to save the main state of the main memory. In addition, a low-speed device such as a disk has been used as a storage destination. On the other hand, a nonvolatile memory that can be used as a main memory has been put into practical use. If the state of the appropriate CPU and peripheral devices is restored together with the state that remains in the nonvolatile main memory when the power is turned off, the system execution state can be restored almost at the time of execution at high speed.

Elnozahy, M., Alvisi, L., Wang, Y.-M. and Johnson, DB: A Survery of Rollback-Recovery Protocols in Message-Passing Systems, Technical Report CMU-CS-99-148, Carnegie Mellon University (1999 ). Joe, D., Glasco, D. and Flynn, M .: Fault Tolerance: Methods of Rollback Recovery, Technical Report CSL-TR-97-718, Stanford University (1997) Morin, C. and Puaut, I .: A Survey of Recoverable Distributed Shared Memory Systems, IEEE Trans. On Parallel and Distributed Systems, Vol. 8, No. 9, pp. 959-969 (1997) Plank, J. S., Beck, M. and Kingsley, G .: Libckpt: Transparent Checkpointing under Unix, USENIX Winter 1995 Technical Conference, pp. 213-223 (1995) Intel and Microsoft: Advanced Power Management BIOS Interface Specification Rev.1.2 (1996) http://www.microsoft.com/hwdev/archive/BUSBIOS/apm 12.asp. Corporation, C. C., Corporation, I., Corporation, M., Ltd., P. T. and Corporation, T .: Advanced Configuration and Power Interface Specification Rev. 2.0a (2002) http://www.acpi.info

  The object of the present invention is based on the premise that the main memory is non-volatile, and even if the system faces sudden power off, the states of the main memory, CPU, and peripheral devices can be restored while maintaining consistency. It is to be.

In order to achieve the object of the present invention, the present invention is a computer system capable of restoring the execution state of the system when the power is turned off, and detects the power off during the system execution and the main memory which is a nonvolatile memory. A power-off interrupt means for generating a power-off interrupt, a CPU state saving means for saving the CPU state by the power-off interrupt, and a log for each access to a peripheral device, or checkpointing before device access Device access storage means to perform, device request storage means to store a request issued to the device, and power supply immediately before detecting that the power was turned off during system execution when the power was turned on and the system started Disconnection detection means and device access save when power is cut off during system execution Based on the information saved by the stage and the device request saving means, the peripheral device state and the access state to the device are restored to determine a point at which the CPU returns, and the system execution is executed from the determined CPU return point. And an execution restarting means for restarting.
Logs every access to peripheral devices, or device access storage means that performs checkpointing before device access, device request storage means that stores requests issued to devices, and power-off during system execution immediately before And a return means for determining a point at which the CPU returns by returning the peripheral device state and the access state to the device based on the information stored by the device access storage means and the device request storage means. A program to be constructed is also the present invention.

  The present invention is basically a software-based approach and does not assume an auxiliary power supply. For this reason, it can be applied to a system in which it is difficult to use an auxiliary power source due to demands for size reduction and weight reduction. Further, the power management specification described above can be supplemented when, for example, a sufficient amount of power is not left in the auxiliary power supply in an unstable power supply environment.

Embodiments of the present invention will be described with reference to the drawings.
FIG. 1 shows the hardware configuration of the embodiment of the present invention, and FIG. 2 shows the software configuration of the system. In the present invention, as shown in FIG. 1, a system in which the main memory 120 is configured by a nonvolatile memory is targeted. Currently, nonvolatile memories such as MRAM and FeRAM that can be read / written by a method similar to the memory used for main memory have been put into practical use. In terms of speed and capacity, they can have sufficient capacity as an alternative to the current main memory.
Further, the state of the CPU 110 when the power is turned off can be restored. A power supply monitoring IC 156 that monitors the power supply 152 is used, and when the power supply 152 supplied to the system falls below a certain value, the CPU 110 is interrupted by an interrupt line 158. By this interruption, the state of the CPU 110 is saved in a specific area by interruption processing (interrupt handler 212 in FIG. 2). If necessary, the attenuation of the power source can be slowed by a processing time for storing the CPU state by a capacitor or the like. The stored CPU state is used by the boot / recovery process 214 during recovery.
Peripheral devices 142 to 144 have the following assumptions. The state when the device is not operating (idle state) can be restored by performing reinitialization and setting of necessary information. Further, if the state of the device before power-off is restored and the access (command) to the same device is re-executed, the device is assumed to perform the same operation as before the stop. Each device on the system operates independently. Don't think if the device is damaged by power off.

<System model>
FIG. 2 shows a system configuration of software according to the embodiment of the present invention. As shown in FIG. 2, kernel (OS) 210, device drivers 220, 230, and 240 that are interfaces between the kernel and devices corresponding to the peripheral devices 142 to 144, and are executed on the OS 210 at the user level. The application program 262, 264, 266, etc.
In such a system composed of a plurality of elements, if a dependency relationship does not occur between the elements, it is possible for each element to independently restore the state and maintain the consistency of the entire system.
In this system, the main memory 120 is non-volatile, and there is no need to restore the state. Also, the state of the CPU 110 can be restored as described above.
Therefore, first, attention is paid to the device drivers 220, 230, and 240, which are elements that generate dependency relationships with the devices 142 to 144. Then, establish a recovery technique that maintains consistency between individual devices and device drivers. By applying the method to each device driver connected to the system, the state of the entire system can be recovered.
In the embodiment of the present invention, code is added to a device driver, and device driver and device information is saved / restored. The added code preserves the necessary information to maintain consistency between the device driver and the device.

<Description of model>
The present embodiment will be described using a message passing system model. In the model of the message passing system, as shown in FIG. 3, execution of processes constituting the system is represented by horizontal arrows, and messages exchanged between them are represented by diagonal arrows. Each process saves its execution state during normal execution. This point is called a “checkpoint”. A point at which each process is restored by a recovery operation after a certain process is stopped due to a failure is called a “recovery point”. Recovery points are selected from the checkpoints of each process. A line connecting the recovery points is called a “recovery line”. It is known that the consistency of the system state after recovery may not be maintained when this recovery line crosses a message.
In the described embodiment, the device is considered as one process constituting the system. This is because, as with each process in the message passing system, each device normally executes in parallel with the CPU. Similarly, the execution of the device driver is regarded as one process, and the interrupt processing in the device driver is also started asynchronously, so that it is regarded as a single process. The exchange (access) with the device including the interrupt is regarded as a message. This is because dependency between the device driver and the state held by the device due to the interaction with the device is similar to the model in the message passing system.
When modeled in this way, in order to maintain system consistency, it is only necessary to find a recovery line that does not cross each access.
From this, first, an appropriate recovery line is found on the basis of the point where the device state can be restored, that is, the idle state of the device. If the state at the time of power-off cannot be used for the device driver or its interrupt processing, the state of the device driver is saved to create a recovery point. Based on this policy, requirements for maintaining consistency between devices and device drivers are extracted.

<Analysis>
Using a diagram similar to FIG. 3, the movement of the device driver is analyzed to extract the requirements.
(Issuing requests to devices)
FIG. 4 shows a modeled device handling state. The horizontal arrow indicates the passage of time and the execution state of each element, and the thin line indicates that the element is not executed. This means an idle state for the device. A vertical arrow represents access to the device. Since there are many cases where read and write accesses are mixed, they are shown as arrows pointing up and down.
In P1 of FIG. 4, the device driver starts issuing a request to the device. After setting and reading the register of the device a plurality of times, the issue of the request is completed in P2. The device then starts executing in response to the request.
If the system is powered off before P1, the device is idle. Therefore, the recovery line in FIG. 4 becomes L1, and the state at the time of power-off can be restored as it is.

In FIG. 4, when the power is cut off between P1 and P2, the state of the recoverable device is the state at P1. If the state at the time of powering off the device driver is restored as it is, the recovery line at this time is a dotted line indicated by L2.
In this case, the state of the device depending on the access from P1 to power off is lost, and the device cannot execute the request accurately. This corresponds to the fact that the consistency of the system state after recovery cannot be maintained when the recovery line L crosses the message in FIG.
There are two possible methods for solving this problem. One is a method of restoring the CPU, main memory, and device states at P1, and starting execution again from P1. This is to make the recovery line a vertical line at P1. The other is a method in which a log of each access is saved during execution, the device state at P1 is restored, and access is performed again using the logs from P1 to power off. Each corresponds to a checkpointing method and a logging method in a message passing system, and the device driver producer may select according to the processing contents performed from P1 to P2.

  After P2, if the power is turned off after the device starts operating, the recovery line may be L3. If the state of the device in P1 is restored and the access to the device performed from P1 to P2 can be executed again, the state of the device in P2 can be restored. Therefore, the access between P1 and P2 is stored as a “request to the device” and is re-executed at the time of recovery to restore the device state at P2. At this time, since the device driver operates regardless of the device, when the power is turned off after P2, the state of the CPU and the main memory can be used as they are and the system can be restored. .

(Interrupt processing)
Completion of the operation of the device operating asynchronously is normally performed using an interrupt. In addition, events generated from the device side such as a mouse and a keyboard are similarly notified to the CPU using an interrupt. FIGS. 5 and 6 show diagrams in which each case is modeled. In each figure, interrupts are represented by thick upward arrows originating from peripheral devices.
FIG. 5 shows a case where a completion notification (interrupt) of a request issued from P1 to P2 occurs at P3. In response to the interrupt, an interrupt service process (ISR: Interrupt Service Routine) of the corresponding device driver is called from the kernel interrupt handler 212 (see FIG. 2). In ISR processing, access for device control, data acquisition from the device, and the like occurs (hereinafter, such processing is referred to as “request post-processing”).
If the process for acquiring data from the device is performed in P3 to P4, the data acquired from the device will be incomplete if the power is cut off before the process is completed in P4. . For this reason, it is necessary to execute again the request issued from P1 to P2 when the system is restarted so that the device holds the same data. As described above, this is performed by re-executing the saved “request to the device” at the time of recovery. From this, the recovery line indicated by L1 is derived. For this reason, in the ISR, it is necessary to invalidate the processing performed until the power is turned off and to change the state to before the occurrence of the interrupt (before P3). That is, in the ISR, it is necessary to save the state at P3 and restore it at the time of recovery.
Since the process is completed between the CPU and the main memory after the device access is completed in the ISR after P4, the system can be re-executed from the power-off point. For this reason, the recovery line is L2. At this time, since it is no longer necessary to return the device state to P2, the stored “request to the device” can be discarded at the time of P4.

FIG. 6 shows a case where an event such as keyboard input or packet arrival occurs at P1, and an interrupt occurs to the CPU at P2. P1 and P2 may be equal.
When the power is cut off between P2 and P3, the data held by the device has not been acquired yet. Further, the device state is lost, and only the device at the point P1 can be restored. The recovery line at this time is L1, and it is necessary to return the ISR state to P2 or earlier as in the above discussion.
Since there is no way to acquire and store the information for recovering the state of the device after P1 from the CPU side, the interrupt generated at this time is completely lost after the system is recovered. However, since it is uncertain whether such an event will occur originally, it is often negligible. This is the keyboard or mouse input.

(Access to shared area)
In the foregoing, it was mentioned that the ISR state may need to be rolled back. If there are elements to be rolled back, you must consider the possibility that other elements may have to be rolled back depending on the element.
FIG. 7 is a case where this situation occurs when the ISR is rolled back. Assume that before the access to the device is completed in the ISR (P5), the ISR writes to the shared data in the shared area at P3, and the device driver reads the data at P4. At this time, a dependency occurs between the state of the ISR and the device driver. When the power is cut off between P4 and P5, the ISR state is rolled back to P2, so the device driver state must be returned to the state before P4.
In order to solve the problem, it is only necessary to prevent the dependency between the ISR and the device driver from occurring within the range in which the ISR is rolled back. From this, one solution is to program the ISR so that write access from the ISR to the shared area is done after the access to the device is completed. If this is difficult, the ISR may keep holding the lock on the synchronization primitive associated with the shared region until the device access is terminated. Thus, the write access from the device driver to the shared area should not be performed until P5. If it is obvious that the ISR and the device driver are not executed in parallel or in parallel, these measures are not necessary.

<Summary of analysis>
The above analysis is summarized as follows.
(1) Access to the device is logged for each access or checkpointing is performed before device access.
(2) Save the request issued to the device.
(3) A request to a stored device can be discarded when a corresponding interrupt occurs and post-processing of the request ends.
(4) If the power is cut off before the device access for request post-processing is completed in the ISR, the state is rolled back before the occurrence of the interrupt.
(5) When a write access is made to a shared area with another element in the ISR, it is performed after the device access is completed, or the ISR is kept holding the lock until the device access is completed.

<Application to device driver>
Here, using the pseudo code example shown in Table 1, a method of applying the above items to the device driver will be described. In Table 1, the role of each method of read, write, and ioctl is the same as the API function of the same name defined by POSIX. The interrupt method is an ISR executed when an interrupt occurs.

[Table 1]
1 void write (void * request) {
2 if (idle == get_device_state ()) {
3 DEV_ACCESS_START ();
4 tell_device_request (request);
5 DEV_REQUEST_SAVE (request_log, request);
6 DEV_ACCESS_END ();
7} else {
8 lock (request_queue);
9 enqueue (request_queue, request);
10 request_count ++;
11 unlock (request_queue);
12}
13 }
14 void read (void * return_buf) {
15 lock (event_buf);
16 while (event_buf_count) {
17 unlock (event_buf);
18 sleep (read_wait);
19 lock (event_buf);
20}
21 memcpy (return_buf, event_buf);
22 event_buf_count--;
23 unlock (event_buf);
twenty four }
25 void ioctl (void * new_state) {
26 dev_state = * new_state;
27 device_state_change (new_state);
28}
29 void interrupt () {
30 do {
31 if (request_done & interrupt_reason ()) {
32 ISR_STATE_SAVE ();
33 post_processing_for_request ();
34 ISR_STATE_DISCARD ();
35 DEV_REQUEST_DISCARD (request_log);
36 lock (request_queue);
37 if (request_count) {
38 request = dequeue (request_queue);
39 DEV_ACCESS_START ();
40 tell_device_request (request);
41 request_count--;
42 DEV_REQUEST_SAVE (request_log, request);
43 DEV_ACCESS_END ();
44}
45 unlock (request_queue);
46}
47 if (event_arose & interrupt_reason ()) {
48 ISR_STATE_SAVE ();
49 lock (event_buf);
50 data = get (event_buf);
51 post_processing_for_event (&data);
52 event_buf_count ++;
53 ISR_SATE_DISCARD ();
54 unlock (event_buf);
55 if (someone_is (read_wait))
56 wakeup (read_wait);
57}
58} while (interrupt_reason ());
59}

また、状態復帰に関する処理および状態復帰に関連する変数は、表３の状態復帰に関する処理，表４の状態復帰に関連する変数を参照されたい。

In the above pseudo code example, refer to the functions related to device access in Table 2 for the role of the functions related to each device access.

For processing related to status recovery and variables related to status recovery, refer to processing related to status recovery in Table 3 and variables related to status recovery in Table 4.

(Idle state recovery)
First, it must be possible to restore the device state when idle. Basically, it is only necessary to initialize the device. However, the device state may be changed separately from an explicit device operation request, such as an ioctl system call. For example, the baud rate setting of the UART device is applicable.
In order to restore these settings, when changing the device state, it is necessary to save the changed device state in an area that can be referred to during recovery (line 26 in Table 1). At the time of recovery, this information is referred to, and the device state is initialized and reset. Note that if the execution of a request affects the idle state of the device, the information is similarly stored in an area that can be referred to during recovery.

(Device access)
It has been stated that access to issue requests to devices is handled by checkpointing or logging.
In the case of the checkpointing method, the main memory state and CPU state of the device driver are saved when access to the device is started. Then, when the access is completed, the information is discarded. At the time of recovery, it is checked whether or not such information exists. If it exists, after the stored main memory state is restored, the execution of the system may be resumed using the CPU state at this time.
At this time, it is not necessary to save all areas in the device driver for saving the main memory state. Since it is sufficient that the state at the start of device access can be restored, the state of the main memory that is changed before the device access ends and needs to be restored may be saved.
When the logging method is used, a log indicating what kind of access is performed for each device access is taken. When the device access is completed, these logs are discarded. At the time of recovery, the existence of logs is confirmed, and if they exist, those logs are executed. Then, the execution of the system may be resumed using the CPU state at the time of power-off.
In Table 1, DEV_ACCESS_START and DEV_ACCESS_END (lines 3, 6, 39, and 43) correspond to the start of access to the device and the end of access to the device, respectively. The logging method does not need to do anything in DEV_ACCESS_START, and changes are made to log in the tell_device_request function.

(Save request to device)
The request to the device must be saved after the access to the device is completed and before the information for restoring the access is discarded (DEV_ACCESS_END). Assume that the request is saved after discarding the access information. If the power is cut off between these processes, the information for re-executing the access is lost, and the request to the device is not saved yet. For this reason, the execution state of the device cannot be restored.
As described above, this information is discarded in the ISR. Points to note about the discarding operation will be described below.
Although the case where the request is issued in the context of the device driver has been described before, the request to the device may be issued in the ISR. If a request for a new device is issued while the device is busy, the request may be queued in the context of the device driver. The queued request is issued to the device in the ISR when the running request is finished. However, even if it is executed within the ISR, it is the same as the discussion described above if it is not in a rollback range. That is, the same correspondence as in normal execution may be performed in the ISR. This corresponds to lines 7-11 and 36-44 in Table 1. In Table 1, DEV_REQUEST_SAVE (line 5, 42) corresponds to the process of logging the request. Also, DEV_REQUEST_DISCARD (35th line) corresponds to log discard.

(ISR rollback)
If the power is cut off before the device access for request post-processing is completed in the ISR, the state of the ISR must be rolled back. For this reason, it is necessary to save the main storage state of the ISR when the execution of the ISR starts. Then, when access to the device is completed, it can be discarded.
In Table 1, ISR_SATE_SAVE (line 32, line 48) corresponds to the process for saving the ISR state, and ISR_STATE_DISCARD (line 34, line 53) corresponds to the process for discarding the stored information.
These processes are similar to the case where device access is restored by the checkpointing method, but it is not necessary to re-execute the ISR after returning, and therefore it is not necessary to save the CPU state. At the time of recovery, the system may be restarted using the CPU state (context executed at the time of interruption) saved when the kernel accepted the interruption.
“Requests to devices” that need to be re-executed need not be lost when the ISR is rolled back. For this reason, it is necessary to discard the information after the ISR information is discarded (line 35), or to restore the discarded request when the ISR state is rolled back. is there.

ISR is often triggered by multiple factors. For example, a transmission end interrupt and a reception interrupt for the network may be processed with the same ISR. In this case, in the ISR, the interrupt factor is specified and the corresponding interrupt is processed. An interrupt may occur during ISR execution. For this reason, the ISR process may loop until there is no interrupt factor.
The range in which the ISR is rolled back needs to be determined after each interrupt factor is specified. For example, it is assumed that the end of the request and the interruption due to the event occur simultaneously. At this time, in the pseudo code shown in Table 1, the ISR is activated, and the event processing is performed following the end of the processing corresponding to the request. If the processing corresponding to the request is finished and the power is cut off during the processing of the 50th line, in this case, the only content that needs to be rolled back is related to the event processing. There is no need to roll back to the processing corresponding to the request. Therefore, ISR_STATE_SAVE and ISR_STATE_DISCARD are inserted separately as shown in the pseudo code in Table 1 (lines 32 and 34 and lines 48 and 53).
Further, when specifying the interrupt factor in the ISR, it is necessary to confirm the “current state”. In the above example, it is assumed that the power is cut off at the 38th line. Processing after the 39th line is continued after recovery, but since the state of the device is lost, it is not possible to continue processing the event before the power is turned off. For this reason, it is necessary to specify the interrupt factor at that time in the 31st, 47th and 58th lines after the return.
The operations for locking the 49th and 54th lines correspond to the explanation of “access to shared area” described above. In line 51, event_buf, which is a shared area with the read method, is accessed. For this reason, the lock acquired in the 49th line is held up to the 54th line. However, if it is known that the context of the ISR and the device driver do not execute at the same time, these operations are not necessary.

<Recovery>
The device state is restored by a callback function. An example of the callback function is shown in Table 5.
[Table 5] Callback function example (simulated code)
1 int recovery_call_back (CPU_t ** cpu_state) {
2 initialize_device (dev_state);
3 recover_memory_area ();
4 replay_request ();
5 return flag;
6}
The functions in Table 5 are called from the boot recovery process 214 (FIG. 2) in the kernel during the recovery process of the entire system. As can be seen from the above description, this function mainly re-initializes the device, restores the main memory state, and re-executes the request to the device. First, as described above, the device re-initialization restores the device state during idling based on the information saved during normal execution (line 2). Next, when there is a main memory state saved by DEV_ACCESS_START (in the case of the checkpointing method) and ISR_STATE_SAVE, each is restored (line 3). If there is a device access log to be re-executed (in the case of a logging method) or a request for a device to be re-executed, these are executed (line 4). Further, at the time of recovery, it is necessary to discard the information stored in ISR_STATE_SAVE, which may be performed after restoring the ISR state. Since the main memory state and log in DEV_ACCESS_START are destroyed by normal operation after recovery, nothing needs to be done in this function.
As described above, when the power is cut off in a range where rollback is necessary, the kernel needs to grasp the CPU state for restarting the system. For this reason, as shown in Table 5, for example, this method allows a pointer to the CPU state structure to be passed by reference, so that the CPU state saved by DEV_ACCESS_START can be returned to the kernel. Further, when the power is cut off in the ISR, it is necessary to use the CPU state stored at the time of occurrence of the interrupt, so that a value is returned as a return value so as to indicate this. Based on the information returned from the callback function of each device driver, the boot recovery processing of the kernel determines the state of the CPU used for re-execution of the system and returns the system.

<Summary of power-off and recovery processing>
The processing in the kernel at the time of power-off and recovery described above is summarized as follows.
(Power-off process)
1. When the power is cut off, an interrupt is notified to the CPU 110 by the power monitoring IC 156 or the like.
2. The kernel interrupt handler 212 saves the state of the CPU 110 in a specific main storage area.
3. System stop (recovery process)
1. The system is turned on.
2. It is determined by the kernel boot recovery process 214 that the power was cut off during the system execution immediately before, and the recovery mode is entered.
3. By the recovery processing, the callback functions 222, 232, and 242 of the device drivers 220, 230, and 240 are called.
4). The callback functions 222, 232, and 242 of each device driver restore the state of each corresponding device and the state of the device driver (recovery function in the pseudo sample code in Table 5).
5). Based on the information returned from each callback function, the boot recovery process 214 determines the point at which the CPU returns.
6). The CPU state at the determined point is restored, and the execution of the system is resumed.
The description so far has described the basic case. For example, in a device that does not require re-execution of a request, it is not necessary to re-execute the request during recovery. Further, it is not necessary to save the request to the device itself. Based on the discussion so far, the method described so far may be applied to the actual device driver according to the characteristics of the target device.

The method of the present invention was implemented using a linux 2.4.4 kernel. The CPU used was a Motorola MPC860 (40 MHz operation). A nonvolatile RAM board using FeRAM was prepared and used as the main memory. As devices, UART and Ethernet (10 Mbps) controllers existing on-chip were used. First, it was examined whether or not the execution state can be restored in the system in which the above-described method is implemented. A process of continuing output to the UART device was executed on the system, and the power was turned off. It was confirmed that when the power was turned on again and the system was restarted, the running process was restored and output to the UART device was started again.
Next, we investigated whether the proposed method was working properly. It was confirmed that the characters immediately before power off may be output from the UART device. This can be considered as a result of the appropriate re-execution of the request to the UART device. In addition, in order to check whether device access restoration and ISR state restoration are operating properly, a push button is attached to the highest level interrupt on the system, and this interrupt is assumed to be a virtual power off. The state was saved. This interrupt was generated while the system was running. After confirming the address when the interrupt occurred, the system was turned off once, and then the system was turned on again to restart the system. For both UART devices and Ethernet devices, even if an interrupt occurred during device access and ISR processing, it was confirmed that the processing that was being executed when the power was turned off continues. As a result, it can be considered that the return of access to the device and the ISR state restoration processing are appropriately performed.
And the overhead was measured by the proposed method on the implemented system. Two tasks were executed when the proposed method was not used (normal execution), when the checkpointing method was used for device access in the proposed method, and when the logging method was also used. Task A executed a process of repeating the operation of outputting one character to the UART device 10,000 times, and the execution time was measured by a time command. The UART baud rate setting is 9600 bps. Task B copied a 2Mbyte NFS file to the remote machine using the cp command. The copy destination was also on NFS. Each result is shown in FIG.
It can be seen that there is almost no increase in execution time when either the checkpointing method or the logging method is used for normal execution.

It is a figure which shows the structural example of the hardware of embodiment. It is a figure which shows the structural example of the software of embodiment. It is a figure explaining the model and recovery line in a message passing system. It is a figure which shows the request issue process to a basic device. It is a figure which shows the interruption process corresponding to a request | requirement. It is a figure which shows the interruption process with respect to an external event. It is a figure which shows the process including access of a shared area. It is a figure for comparing the execution time by each mounting method.

Claims (2)

A computer system capable of restoring the running state of the system when the power is turned off,
A main memory which is a nonvolatile memory;
A power-off interrupt means for detecting power-off during system execution and generating a power-off interrupt;
CPU state storage means for storing the state of the CPU by the power-off interrupt;
Device access storage means to log every access to peripheral devices, or checkpoint before device access,
Device request storage means for storing a request issued to the device;
When power is turned on and the system starts up, immediately before power-off detection means for detecting that power was cut off during system execution immediately before,
When the power is cut off during system execution immediately before, the information stored by the device access storage means and the device request storage means restores the peripheral device state and the access state to the device and returns the point where the CPU returns. A return means to determine;
An execution restarting means for restarting the system execution from the determined return point of the CPU. Device access storage means to log every access to peripheral devices, or checkpoint before device access,
Device request storage means for storing a request issued to the device;
When the power is cut off during system execution immediately before, the information stored by the device access storage means and the device request storage means restores the peripheral device state and the access state to the device and returns the point where the CPU returns. A program that causes a computer system to construct a return means for determination.

Images