WO2012001783A1 - データ復元プログラム、データ復元装置およびデータ復元方法 - Google Patents

データ復元プログラム、データ復元装置およびデータ復元方法 Download PDF

Info

Publication number
WO2012001783A1
WO2012001783A1 PCT/JP2010/061179 JP2010061179W WO2012001783A1 WO 2012001783 A1 WO2012001783 A1 WO 2012001783A1 JP 2010061179 W JP2010061179 W JP 2010061179W WO 2012001783 A1 WO2012001783 A1 WO 2012001783A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
volatile memory
processor
restoration
parity
Prior art date
Application number
PCT/JP2010/061179
Other languages
English (en)
French (fr)
Inventor
鈴木　貴久
浩一郎 山下
宏真 山内
康志 栗原
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2010/061179 priority Critical patent/WO2012001783A1/ja
Priority to JP2012522388A priority patent/JP5382220B2/ja
Priority to EP10854080.8A priority patent/EP2590083A4/en
Publication of WO2012001783A1 publication Critical patent/WO2012001783A1/ja
Priority to US13/730,514 priority patent/US9037808B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/30—Means for acting in the event of power-supply failure or interruption, e.g. power-supply fluctuations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076—Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G06F12/0646—Configuration or reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/10—Indexing scheme relating to G06F11/10
    • G06F2211/1002—Indexing scheme relating to G06F11/1076
    • G06F2211/1059—Parity-single bit-RAID5, i.e. RAID 5 implementations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1028—Power efficiency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/25—Using a specific main memory architecture
    • G06F2212/254—Distributed memory

Definitions

  • the present invention relates to a data restoration program, a data restoration device, and a data restoration method for restoring data stored in a volatile memory mounted on a processor.
  • a register and a local memory inside a processor are configured by a volatile memory, and internal information is not held unless power is supplied. Therefore, the operating system (hereinafter referred to as “OS (Operating System)”) or the like normally turns off the data stored in the processor registers and local memory before the power is turned off. A measure is taken to save to a storage device outside the processor.
  • OS Operating System
  • the capacity of local memory has increased, and the time required for saving has increased significantly compared to registers and caches, and there is a high possibility that it will greatly affect the deterioration of power efficiency.
  • the capacity of registers and caches is several tens to several hundreds bytes, or several tens of kilobytes, but the capacity of local memory is often several hundreds of kilobytes. Therefore, considering the amount of power required to save the data stored in the local memory, there is a problem that a sufficient effect cannot be obtained even though the low power consumption technology is adopted.
  • RAID technology has been cited as a solution to the data saving process in the volatile memory as described above, but the difference in configuration between the hard disk that distributes data by RAID and the local memory of the multi-core processor is considered. It does not lead to a sufficient effect.
  • RAID technology is based on the premise of a hard disk drive failure.
  • the conventional RAID technology is configured to distribute data and generate redundant data for restoration assuming that one or two HDDs (Hard disk Drive) are stopped.
  • the present disclosure provides a data restoration program, a data restoration device, and a data restoration method that enable a high-speed power supply stop without waiting for data stored in a volatile memory to be saved
  • the purpose is to provide.
  • the present disclosure provides a plurality of volatile memories and a plurality of processors in the multi-core processor by a computer that can access a multi-core processor including a plurality of processors that access the volatile memory.
  • a stop instruction to any one of the processors is detected, and the stop instruction is detected, the processor is stored in a volatile memory that is accessed by an operating processor group other than the processor that has received the stop instruction. Based on the parity data, the data stored in the volatile memory accessed by the processor that has received the stop instruction is restored in the shared memory accessible by the operating processor group.
  • the present data restoration program, data restoration device, and data restoration method have an effect of enabling a high-speed power supply stop without waiting for the data stored in the volatile memory to be saved.
  • FIG. 3 is a flowchart illustrating an operating procedure of the OS when power is restored in the first embodiment. It is a flowchart which shows the operation
  • FIG. 6 is a block diagram illustrating an internal configuration of a RAID controller in Embodiment 2.
  • FIG. 12 is a flowchart illustrating an operating procedure of the OS when the power is stopped in the second embodiment. It is a flowchart which shows the operation
  • 10 is a flowchart illustrating an operation procedure of a data saving unit according to the second embodiment.
  • 10 is a flowchart illustrating an operation procedure of a restoration data generation unit according to the second embodiment. It is a flowchart which shows the operation
  • 10 is a flowchart illustrating an operating procedure of the OS when power is restored in the second embodiment.
  • FIG. 10 is a block diagram illustrating an internal configuration of a RAID controller according to a third embodiment. It is a flowchart which shows the operation
  • FIG. 1 is an explanatory diagram showing an example of the data restoration processing according to the present embodiment.
  • the multi-core processor 100 is a processor group including a plurality of CPUs (for example, CPU # 0 to CPU # 3).
  • the multi-core processor 100 includes a power source 101, a local memory bus 102, and a shared memory bus 103 in addition to a plurality of CPUs.
  • the power supply 101 supplies power to each CPU and a local memory accessed by each CPU. Further, the power supply 101 can stop supplying power only to the designated CPU and local memory in accordance with an instruction from the OS. Similarly, the power supply 101 can restore the supply of power only to the designated CPU and local memory in accordance with an instruction from the OS. Further, each CPU is controlled by the OS, but when the CPU is stopped, the corresponding OS is also stopped. Therefore, each OS controls the power-off of its own CPU and the power-on of other CPUs.
  • the local memory bus 102 is a bus that enables access between each CPU and the local memory. Each CPU can also access the local memory of another processor via the local memory bus 102.
  • the shared memory bus 103 is a bus that allows the multi-core processor 100 and the shared memory 104 to be accessed.
  • the shared memory 104 is a non-volatile memory or a memory that is always supplied with electric power and has no risk of data loss.
  • the multi-core processor 100 is not equipped with the data restoration device 110, and the OS of the CPU to be stopped (for example, the OS of CPU # 0) starts the power supply stop process.
  • the OS causes the shared memory 104 to save the register of the CPU to be stopped and the data in the local memory.
  • the OS writes back the cache contents to the shared memory 104.
  • the OS notifies the other CPU OS of the power stop.
  • a power supply stop instruction is issued from the OS to the power supply 101, and the power supply is turned off.
  • the operating system of the operating CPU (for example, the OS of CPU # 1) starts the power recovery processing of the stopped CPU.
  • the OS first instructs the power supply 101 to start power supply to the CPU to be restored, and turns on the power.
  • the OS restores the registers saved in the shared memory 104 and the data in the local memory into the CPU registers and the local memory that have been restored.
  • FIG. 2 is an explanatory diagram showing a configuration example of a multi-core processor using RAID technology.
  • a RAID technique may be used as a countermeasure plan for omitting the data saving time when the power supply is stopped. Specifically, the data stored in the local memory of the stopped CPU can be restored from the redundant data without avoiding the data in the local memory when the power is stopped.
  • FIG. 3 is an explanatory diagram showing the operation of RAID1
  • FIG. 4 is an explanatory diagram showing the operation of RAID5.
  • the RAID technology is a technology for operating a plurality of hard disk drives (hereinafter referred to as “HDD”) as a single virtual HDD.
  • HDD hard disk drives
  • FIG. 3 is an explanatory diagram showing the operation of RAID1
  • FIG. 4 is an explanatory diagram showing the operation of RAID5.
  • the RAID technology is a technology for operating a plurality of hard disk drives (hereinafter referred to as “HDD”) as a single virtual HDD.
  • HDD hard disk drives
  • parity data for example, Par 1 or Par 2
  • storage data for example, data A to F
  • redundant data for example, Par 1 or Par 2
  • parity data for example, Par 1 or Par 2
  • the data stored in the damaged HDD is restored by obtaining an exclusive OR of the data stored in the HDDs other than the damaged HDD as described below.
  • Any of the methods described above can protect data from an unexpected HDD failure by making data stored in the HDD redundant. Therefore, conventionally, there has been a method of protecting data stored in a volatile memory such as a local memory of a CPU by using RAID 5 or RAID 6 similar to RAID 5.
  • the contents of the stopped local memory are restored from the parity data, saved in the shared memory 104, and adapted to the configuration of the operating local memory. Reconstruct new parity data.
  • the data restoration device 110 restores the contents of the local memory from the redundant data onto the shared memory 104 after the power supply to the CPU # 1 and the local memory 1 is stopped (step S1). Specifically, DATA2 stored in the local memory 1 is restored by DATA1, DATA3, and Parity1 and stored in the save area # 1 in the shared memory 104. Actually, subsequently, DATA6 stored in the local memory 1 is similarly restored by DATA5, DATA3, DATA4, and Parity2, but description thereof is omitted here.
  • the data restoration device 110 reconstructs the parity data according to the number of operating CPUs (step S2). That is, before the CPU # 1 is stopped, parity data that can restore the data stored in the local memories is stored using the local memories of the four CPUs. However, CPU # 1 has stopped. Therefore, after the stop of CPU # 1, the local memory of the three operating CPUs is used to generate (reconstruct) parity data that can restore the data stored in each local memory. Store each in memory.
  • FIG. 5 is a block diagram illustrating a hardware configuration of the data restoration apparatus.
  • the data restoration device 110 includes a CPU (Central Processing Unit) 501, a ROM (Read-Only Memory) 502, a RAM (Random Access Memory) 503, a magnetic disk drive 504, a magnetic disk 505, and an I / F (Interface) 506. Each component is connected by a bus 500.
  • CPU Central Processing Unit
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • magnetic disk drive 504 a magnetic disk 505
  • I / F Interface
  • the CPU 501 governs overall control of the data restoration apparatus.
  • the ROM 502 stores various programs such as a boot program and a data restoration program for realizing data restoration processing.
  • the RAM 503 is used as a work area for the CPU 501.
  • the magnetic disk drive 504 controls reading / writing of data with respect to the magnetic disk 505 according to the control of the CPU 501.
  • the magnetic disk 505 stores data written under the control of the magnetic disk drive 504.
  • the magnetic disk 505 was mentioned as an example of the storage medium in FIG. 5, other media such as an optical disk or a semiconductor memory may be used.
  • I / F 506 is a bus according to a predetermined communication standard, each CPU in the multi-core processor, volatile memory (local memory) accessed by each CPU, Mutual communication with the shared memory 104 is realized.
  • FIG. 6 is a block diagram showing a functional configuration of the data restoration apparatus.
  • the data restoration apparatus 110 includes a stop detection unit 601, a restoration unit 602, a creation unit 603, a storage unit 604, a start detection unit 605, and a return unit 606.
  • the functions (stop detection unit 601 to return unit 606) serving as the control unit execute a program stored in a storage device such as the ROM 502, RAM 503, and magnetic disk 505 shown in FIG.
  • the function is realized by the I / F 506.
  • the stop detection unit 601 has a function of detecting a stop instruction to the processor from a higher-level program such as an OS. Specifically, the stop detection unit 601 detects a stop instruction to any of the processors (processor 0 to processor n) in the multi-core processor 600. The detection result is stored in a storage area such as the RAM 503 and the magnetic disk 504.
  • the restoration unit 602 has a function of restoring data stored in the volatile memory to which power supply has been stopped to the shared memory 104. Specifically, when the detecting unit 601 detects a stop instruction, the restoration unit 602 is based on parity data stored in a volatile memory accessed by an operating processor group other than the stop instruction destination processor. Restore data stored in volatile memory. The restoration unit 602 stores the restored data in the shared memory 104 that can be accessed by the active processor group. The restored data is temporarily stored in a storage area such as the RAM 503 and the magnetic disk 505.
  • the creation unit 603 has a function of creating new parity data. Specifically, the creation unit 603 creates parity data for restoring the data stored in the volatile memory accessed by the operating processor group after the restoration unit 602 performs the data restoration.
  • the created parity data is stored in a storage area such as the RAM 503 and the magnetic disk 505.
  • the storage unit 604 has a function of storing the created parity data in the volatile memory of the operating processor. Specifically, the storage unit 604 stores the parity data created by the creation unit 603 in a volatile memory accessed by each operating processor group.
  • the storage unit 604 stores the volatile memory other than the volatile memory in which the data restored by the parity data is stored.
  • parity data for restoring data stored in the volatile memory 1 is stored in a volatile memory of an operating processor other than the volatile memory 1.
  • the creation unit 603 creates parity data for restoring new data when data is newly added to or updated with new data in the volatile memory of one of the plurality of processors. That is, whenever the data stored in the volatile memory is updated, parity data for restoring the latest data is created.
  • the storage unit 604 uses the volatile memory created by the creation unit 603 other than the volatile memory in which new data is added or updated to new data among the volatile memories accessed by the respective active processor groups. Store in volatile memory.
  • the start detection unit 605 has a function of detecting an instruction from the host program to the processor. Specifically, the start detection unit 605 detects start of power supply to a stopped processor among the plurality of processors. The detection result is stored in a storage area such as the RAM 503 and the magnetic disk 505.
  • the restoration unit 606 has a function of restoring the saved data to the volatile memory of the processor for which power supply has been started. Specifically, when the start detection unit 605 detects the start of power supply, the return unit 606 accesses the data restored to the shared memory 104 to the volatile memory that is accessed by the processor in which the start of power supply is detected. To store.
  • the start detection unit 605 detects the start of power supply during the data recovery by the recovery unit 602
  • the data stored in the volatile memory that has not been recovered in the shared memory 104 is stored. is there.
  • the restoration unit 606 restores and restores the parity data stored in the volatile memory accessed by the operating processor group.
  • the creation unit 603 creates parity data for restoring the data stored in the volatile memory accessed by the operating processor group when the data is restored by the restoration unit 606 described above.
  • the storage unit 604 stores the parity data created by the creation unit 603 in a volatile memory other than the volatile memory in which data restored by the parity data is stored. That is, parity data for restoring data stored in the volatile memory 1 is stored in a volatile memory group in operation other than the volatile memory 1.
  • the data restoration device 110 has a read detection function for detecting a read request for data stored in the volatile memory from any processor. You may prepare.
  • the data restoration device 110 indicates that the data is stored in the shared memory 104. Notify the processor that executes the reading of. Based on the notification, the processor that has received the notification can read the data stored in the shared memory 104 in which the desired data is actually stored, instead of the volatile memory in which the desired data is not stored.
  • the data restoration device 110 uses the function of the restoration unit 602 to restore the data stored in the stopped volatile memory based on the parity data. Furthermore, the data restoration device 110 can read desired data by notifying the storage destination of the restored data to the processor that executes the data reading.
  • the data restoration device 110 may selectively apply either the data restoration processing according to the present embodiment or the conventional data saving processing according to the number of operating processors. If the number of operating processors becomes extremely small, the proportion of the amount of parity data in the capacity of the operating volatile memory increases. In other words, the capacity of the volatile memory that can be used by the processor for the original processing is reduced, resulting in a decrease in the function of the processor, resulting in deterioration of power efficiency.
  • the present embodiment is based on the threshold value using a predetermined value for the number of CPUs as a threshold value according to the total number of processors of the multi-core processor 600 to which the data restoration device 110 is applied and the capacity of the volatile memory. It can be configured to automatically determine which one of the data restoration processing according to the embodiment and the conventional data saving processing is used. By performing the determination using the threshold value, the data restoration apparatus 110 can support the operation with the most power efficiency according to the operating state of each processor in the multi-core processor 600.
  • the OS being executed by the multi-core processor 600 causes a process of determining whether or not the number of operating processors is equal to or greater than a threshold value.
  • the processor receives a stop instruction to one of the multi-core processors 600, if the number of operating processors is determined to be equal to or greater than the threshold value, the OS determines the processor that received the stop instruction and the processor An instruction to stop power supply to the volatile memory accessed by the processor is output to the power supply 101, and the power supply is immediately stopped.
  • the data restoration apparatus 110 executes the data restoration process according to the present embodiment, the stored data is restored in the shared memory 104 even if the power supply to the volatile memory is stopped. .
  • the OS waits for the stop of power supply until the data in the volatile memory is saved in the shared memory 104, as in the prior art.
  • the OS determines that the number of active processors is not greater than or equal to the threshold value, the OS stores data stored in the volatile memory of the processor that has received the stop instruction. Transfer to shared memory 104. Further, the OS outputs an instruction to stop power supply to the volatile memory to the power supply 101 after the data stored in the volatile memory is transferred to the shared memory 104 by the transfer described above.
  • FIG. 7 is a flowchart showing a procedure of data restoration processing by the data restoration device.
  • the flowchart of FIG. 7 shows a procedure until the data restoration device 110 automatically restores the data stored in the volatile memory and stores it in the shared memory 104 when receiving a stop instruction to the processor. Yes.
  • the multi-core processor 600 provided with the data restoration device 110 immediately turns on the power without waiting for the saving processing of the contents stored in the volatile memory of the processor that has received the stop instruction. Can be stopped.
  • the data restoration device 110 first determines whether or not a stop instruction is detected by the stop detection unit 601 (step S701). If it is determined in step S701 that a stop instruction has been detected (step S701: Yes), the data restoration device 20 proceeds to the process in step S704 and restores data stored in the volatile memory to be stopped. Process.
  • step S701 If it is determined in step S701 that no stop instruction has been detected (step S701: No), the data restoration apparatus 110 stores new data in the volatile memory in which the OS is currently operating. It is determined whether or not (step S702). In step S702, whether or not to store new data is determined depending on whether or not a write instruction is received from a higher-level program (OS (Operating System) here) that operates multi-core processor 600.
  • OS Operating System
  • step S702 When it is determined in step S702 that new data is to be stored (step S702: Yes), the data restoration device 110 uses the creation unit 603 to generate parity data for restoring new data stored in the volatile memory. Created and stored in the volatile memory of the operating processor by the storage unit 604 (step S703).
  • step S701 if it is determined in step S701 that a stop instruction has been detected, the data restoration device 110 causes the restoration unit 602 to transfer the data stored in the volatile memory of the processor stopped using the parity data to the shared memory 104. Restoration is performed (step S704).
  • step S702 After the processing of steps S703 and S704 is completed, or when it is determined in step S702 that new data is not stored (step S702: No), the data restoration device 110 detects a start instruction by the start detection unit 605. It is determined whether or not it has been done (step S705).
  • step S705 When the start instruction is detected in step S705 (step S705: Yes), the data restoration device 110 uses the restoration unit 606 to restore the data restored in step S704 to the shared memory 104 to the volatile memory of the started processor ( Step S706). On the other hand, when the start instruction is not detected in step S705 (step S705: No), the process proceeds to step S707 without performing the process in step S706.
  • step S707 determines whether or not an end instruction has been received from an upper system such as an OS (step S707). If the data restoration device 110 does not receive an end instruction (step S707: No), the processing from steps S701 to S706 is repeated. In step S707, when the data restoration apparatus 110 receives an end instruction (step S707: Yes), the series of processing ends.
  • the data stored in the volatile memory is restored even if the power supply to any of the processors of the multi-core processor 600 and its volatile memory is stopped. be able to. Therefore, unlike the conventional case, the CPU can be stopped at high speed and power consumption can be greatly reduced without considering saving of data in the volatile memory.
  • the data restoration apparatus 110 can also automatically select a data saving method when the power is stopped in the multi-core processor 600 according to the number of operating processors.
  • Embodiments 1 to 3 in which the function of the data restoration device 110 is realized by a RAID controller will be described in detail.
  • FIG. 8 is a block diagram illustrating a configuration example of a multi-core processor including a RAID controller.
  • the function of the data restoration apparatus 110 is realized by the RAID controller 801.
  • each CPU and local memory are connected by a local memory bus 102.
  • Each CPU is also configured to be able to access the local memory of another CPU via the local memory bus 102.
  • FIG. 9 is a block diagram illustrating an internal configuration example of the RAID controller according to the first embodiment.
  • the RAID controller 801 includes a memory access monitoring unit 901, a parity generation unit 902, a parity reconstruction unit 903, a command reception unit 904, a restored data generation unit 905, and a data save unit 906.
  • the memory access monitoring unit 901 monitors access from the CPU to the local memory. Further, the parity generation unit 902 generates parity data for restoring data stored in the local memory.
  • the parity reconstructing unit 903 updates the corresponding parity data when the local memory is written.
  • the command receiving unit 904 receives a command output from the OS and executes processing according to the content of the command.
  • the restored data generation unit 905 restores the data stored in the stopped local memory in the shared memory 104 using the parity data.
  • the data saving unit 906 temporarily saves the data stored in the local memory when the power is stopped.
  • the data area of the local memory is divided into an area used as a normal data area and a parity data area. Further, if there are N local memories that are currently operating, and the value of the address x of the mth local memory is rewritten in the currently operating local memory, (N ⁇ x + m) / (N ⁇ 1) ... Parity data is generated by reading data from a combination of x and m in which the integer part of equation (1) is the same.
  • parity data is written to the yth address of the (N-1-k) th local memory, where y is the integer part of (N ⁇ x + m) / (N-1) 2 (2) and the remainder is k.
  • parity data is generated by exclusive OR as in the RAID5 technique.
  • the parity generation unit 902 reconstructs the parity data at the y-th address of the k-th local memory with the number of currently operating local memories being N from the above formulas (1) and (2). .
  • FIG. 10 is an explanatory diagram showing an example of normal operation. First, the normal operation of the RAID controller 801 will be described. As shown in FIG. 10, when an access to the local memory occurs from any of the operating CPUs, the normal-time RAID controller 801 generates parity data according to the access contents.
  • the parity generation unit 902 generates parity data (Parities 11, 21, 31) for restoring the data after the writing process.
  • the generated parity data is stored in the parity data area of the CPU # 3 by the parity generation unit 902.
  • FIG. 11 is a flowchart showing the operation procedure of the RAID controller at the normal time.
  • the normal time is an operation of only the CPU in which the multi-core processor is operating, and means a state in which an operation such as a stop of the CPU or a return of the stopped CPU has not occurred.
  • the RAID controller 801 first detects writing to the local memory in the memory access monitoring unit 901 (step S1101). Thereafter, the RAID controller 801 first reads the corresponding data in the parity generation unit 902 (step S1102) and generates parity data (step S1103). Thereafter, the RAID controller 801 updates the corresponding parity data (step S1104), and ends a series of processing.
  • the normal-time RAID controller 801 generates parity data for restoring the written data each time writing to the local memory is detected, and generates the generated parity data. Is updated as the latest parity data. Therefore, the latest data can be restored no matter what timing the power supply stops.
  • FIG. 12 is an explanatory diagram illustrating an operation example when the power is stopped.
  • the local memory of the stopped CPU also immediately saves the stored data without saving it.
  • the power supply is stopped and the power supply is stopped.
  • the RAID controller 801 restores the content of the data stored in the local memory whose power is stopped from the redundant data stored in the operating local memory on the shared memory 104 (step S1201).
  • FIG. 13 is a flowchart illustrating the operation procedure of the OS when the power is stopped in the first embodiment.
  • the flowchart of FIG. 13 represents the instruction contents output from the OS to the RAID controller 801 and the procedure when the power is stopped.
  • the OS first determines whether or not the number of operating CPUs is equal to or less than a specified value (step S1301). If it is determined in step S1301 that the number of operating CPUs is not less than the specified value (step S1301: No), the OS determines whether parity data is being reconstructed (step S1302).
  • step S1302 If it is determined in step S1302 that the parity is being reconstructed (step S1302: Yes), the OS waits until the reconstruction is completed (step S1303), and saves the contents of the register in the shared memory 104 (step S1303). Step S1304). If it is determined in step S1302 that the parity is not being reconstructed (step S1302: No), the process proceeds to step S1304 without waiting in step S1303.
  • the OS flushes the cache (step S1305) and notifies the RAID controller 801 that the target CPU is stopped (step S1306). Further, the OS notifies the other processor of the stop of the target CPU (step S1307), operates the power supply mechanism (step S1308), and completely stops the power supply to the target CPU. End the process.
  • step S1301 determines whether the number of CPUs is equal to or less than the specified value (step S1301: Yes). If it is determined in step S1301 that the number of CPUs is equal to or less than the specified value (step S1301: Yes), the OS saves the contents of the register in the shared memory 104 (step S1309) and shares the contents of the local memory. Save to the memory 104 (step S1310). Thereafter, the OS flushes the cache (step S1311), and proceeds to the process of step S1307.
  • FIG. 14 is a flowchart showing an operation procedure by the RAID controller when the power is stopped.
  • the flowchart of FIG. 14 shows what processing each functional unit in the RAID controller 801 performs when the power is stopped.
  • the RAID controller 801 starts operation when the command receiving unit 904 receives a power stop command as a trigger.
  • the command receiving unit 904 determines whether or not the number of CPUs after stopping is equal to or less than a specified value (step S1401). If it is determined in step S1401 that the number of CPUs is not less than the specified value (step S1401: No), the command receiving unit 904 starts saving the contents of the local memory of the stopped CPU (step S1402), and the parity Data reconstruction is started (step S1403).
  • the data saving unit 906 searches for unsaved data (step S1411).
  • the restoration data generation unit 905 reads the corresponding data using the search result in step S1411 (step S1421), and generates restoration data (step S1422).
  • the restoration data is generated by the restoration data generation unit 905, the data saving unit 906 saves the restoration data in the shared memory 104 (step S1412).
  • the saving process by the data saving unit 906 is repeatedly performed until there is no unsaved data.
  • step S1401 determines whether the number of CPUs is equal to or less than the specified value (step S1401: Yes). If it is determined in step S1401 that the number of CPUs is equal to or less than the specified value (step S1401: Yes), the saving of the local memory contents of the stopped CPU is started in the same manner as in step S1402 (step S1404). In the case of step S1404, unlike the case of step S1402, conventional saving processing is performed. That is, power supply to the local memory is continued until the saving process in step S1404 is completed.
  • step S1403 when the saving process of step S1402 is started, after the process of step S1403, the parity reconstruction unit 903 searches for unreconstructed data (step S1431). Thereafter, the parity generation unit 902 reads the corresponding data (step S1441) and generates parity data (step S1442). Thereafter, the parity generation unit 902 writes the generated parity data to each local memory (step S1443). The generation of the parity data described above is repeated until there is no unreconstructed data.
  • FIG. 15 to 18 are explanatory diagrams showing the procedure of the stopping operation of CPU # 1.
  • FIG. 15 shows a state where the local memory 1 is stopped. As the local memory 1 stops, the data stored in the local memory 1 must be restored. At the same time, the parity data must be reconstructed so that the stored data can be restored even if the operating local memory is stopped.
  • the DATA 21 is restored by the DATA 11, 31 and the parity 11, 21, 31.
  • the restored data is stored in the shared memory 104 by the data saving unit 906.
  • the parity generation unit 902 generates parity data (Parities 11, 31) for restoring data stored in the operating local memory.
  • the generated parity data is stored in the local memory 3 by the parity reconstruction unit 903.
  • the restoration data generation unit 905 DATA 22 is restored by DATA 12, 41 and Parity 41, 12, 22.
  • the restored data is stored in the shared memory 104 by the data saving unit 906.
  • the parity generation unit 902 generates parity data (Parities 41 and 12) for restoring data stored in the operating local memory.
  • the generated parity data is stored in the local memory 2 by the parity reconstruction unit 903.
  • the restored data generation unit 905 restores the DATA 23 by the DATA 32, 43 and the Parities 23, 33, 43.
  • the restored data is stored in the shared memory 104 by the data saving unit 906.
  • the parity generation unit 902 generates parity data (Parities 32 and 42) for restoring data stored in the operating local memory.
  • the generated parity data is stored in the local memory 0 by the parity reconstruction unit 903.
  • FIG. 19 is an explanatory diagram showing an example of access to the local memory when the power is stopped. Depending on the contents of the processing executed by the multi-core processor 800, access to the local memory while the power is stopped may occur as shown in FIG. Access means a reading process for reading data and a writing process for writing data.
  • the RAID controller 801 detects the access from the CPU # 0, takes the request of the CPU # 0 instead of the local memory 1, and moves to the memory (for example, the shared memory 104) where the target data actually exists. Induce.
  • FIG. 20 is a flowchart showing an access procedure by the RAID controller when the power is stopped.
  • the flowchart of FIG. 20 shows the difference in operation of the RAID controller 801 according to the access contents when an access to the stopped local memory occurs.
  • the memory access monitoring unit 901 starts processing with detection of access to a local memory being stopped as a trigger.
  • the memory access monitoring unit 901 first determines whether or not the detected access is a read process (step S2001). If it is determined in step S2001 that the detected access is a read process (step S2001: Yes), the memory access monitoring unit 901 determines whether or not the access destination data has been reconfigured (step S2002).
  • step S2002 If it is determined in step S2002 that the data is not reconfigured data (step S2002: No), the memory access monitoring unit 901 stores the data to be accessed from the parity data in the local memory because there is currently no data to be accessed. The restored data is restored (step S2003). On the other hand, if it is determined in step S2003 that the data has been reconfigured (step S2002: Yes), it means that the target data has been restored to the shared memory 104. Therefore, the memory access monitoring unit 901 reads the data saved in the shared memory 104 (step S2004).
  • step S2001 If it is determined in step S2001 that the access is a read process, the target data is read by the process in step S2003 or S2004. Therefore, the memory access monitoring unit 901 returns data to the reading source CPU (step S2005) and ends the series of processes.
  • step S2001 If it is determined in step S2001 that the read process is not performed (step S2001: No), the memory access monitoring unit 901 determines that the access detected this time is a write process. Therefore, the memory access monitoring unit 901 writes the target data to the save area of the shared memory 104 (step S2006), and ends the series of processes. If the access is a writing process, the data itself is updated by this access. Therefore, it is not necessary to restore the data stored in the local memory as in the reading process.
  • step S2003 the subject of the processing when restoring the data is the restored data generation unit 905.
  • the restored data generation unit 905 starts a series of processes triggered by the process in step S2003.
  • the restoration data generation unit 905 first reads corresponding data (parity data) (step S2011), and uses the read data to generate data stored in the local memory as restoration data (step S2012).
  • the data generated in step S2012 is returned to the memory access monitoring unit 901 and used for the processing in step S2005.
  • a specific example of the procedure of reading and writing to the local memory being stopped will be described.
  • FIGS. 21 and 22 are explanatory diagrams showing the reading procedure to the local memory when the power is stopped.
  • a request for read processing is generated from the CPU # 0 to the local memory 1 of the stopped CPU # 1. Since the CPU # 0 sequentially reads data stored in the local memory 1 (actually stored), first, the first DATA 21 is set as data to be read.
  • the memory access monitoring unit 901 When the memory access monitoring unit 901 detects the reading process from the CPU # 0, the memory access monitoring unit 901 determines whether or not the DATA 21 is reconfigured data in the shared memory 104. In the example of FIG. 21, data 21 to 23 in the local memory 1 is data that has been reconfigured in the shared memory 104. Therefore, the memory access monitoring unit 901 causes the CPU # 0 to read the DATA 21 stored in the shared memory 104.
  • the CPU # 0 sequentially reads the data stored in the local memory 1 from the DATA 21, but as illustrated in FIG. 22, when the target data is after the DATA 24, the data cannot be read from the shared memory 104. Therefore, the RAID controller 801 restores data that has not been reconstructed by the restoration data generation unit 905.
  • the restoration data generation unit 905 includes the DATAs 14 and 34 and the Parity 14 stored in the local memories 0, 2, and 3 of the operating CPUs # 0, 2, and 3. , 24, and 34, the data 24 can be obtained by generating data that satisfies the exclusive OR operation. Data 25 and later can be restored in the same procedure.
  • the memory access monitoring unit 901 can read the data restored by the restored data generation unit 905 by the CPU # 0, so that even the stopped local memory 1 can read the data as if it is in operation.
  • FIG. 23 and 24 are explanatory diagrams showing a writing procedure to the local memory when the power is stopped.
  • a request for writing processing from the CPU # 0 to the local memory 1 of the stopped CPU # 1 is generated. Since the CPU # 0 sequentially writes in the order of addresses in the data stored in the local memory 1 (actually stored), first, the first DATA 21 is set as the data to be written.
  • the memory access monitoring unit 901 When the memory access monitoring unit 901 detects a writing process from the CPU # 0, the memory access monitoring unit 901 writes the DATA 21 to the shared memory 104. Thereafter, even if the target data shifts to DATA 24 as shown in FIG. 24, the memory access monitoring unit 901 causes DATA 24 to be written to the shared memory 104 in the same manner as the processing of FIG.
  • the memory access monitoring unit 901 may guide the CPU # 0 to uniformly write to the shared memory 104.
  • the processing contents of the RAID controller 801 differ depending on whether the access is a read process or a write process.
  • read processing if the data to be read is reconstructed data, it may be guided to simply read from the shared memory 104, but it is not reconstructed data In this case, it is necessary to generate restored data one by one and read it into the access source CPU.
  • FIG. 25 is an explanatory diagram illustrating an operation example when power is restored. Next, an operation at the time of power recovery in which power is once again supplied to the CPU whose power has been stopped will be described. As shown in FIG. 25, when the power supply to the CPU # 1 and the local memory 1 is resumed, the RAID controller 801 first restores the data saved in the shared memory 104 to the local memory 1 (step S2501).
  • the RAID controller 801 reconstructs the parity data according to the number of operating CPUs after the power is restored (step S2502). As CPU # 1 is restored, CPUs # 0 to # 3 are in operation. Therefore, the local memory of each CPU stores parity data for restoring the data stored in the local memory in the parity areas of three local memories other than the local memory.
  • FIG. 26 is a flowchart illustrating the operation procedure of the OS when the power is restored in the first embodiment.
  • the flowchart of FIG. 26 shows a procedure until the stopped CPU receives a return instruction from another CPU and resumes normal operation processing.
  • the OS starts the operation triggered by the power-return determination process in the CPU other than the stopped CPU.
  • the OS operates the power supply mechanism of the stopped CPU from the other CPU described above (step S2601).
  • the OS notifies the RADIUS controller 801 of the return in the target CPU for power return (step S2611). Subsequently, the OS restores the contents of the register (step S2612), and notifies the other processor (other CPU) of the return (step S2613). Thereafter, the OS resumes the process of the restored CPU (step S2614), thereby ending the series of restoration processes.
  • FIG. 27 is a flowchart showing an operation procedure by the RAID controller when power is restored.
  • the flowchart of FIG. 27 represents the operation of the RAID controller 801 when receiving a power supply return instruction from the OS.
  • the RAID controller 801 starts processing in the command reception unit 904, triggered by reception of a command related to power recovery output from the OS.
  • the command receiving unit 904 determines whether or not the data to be restored is being reconstructed (step S2701).
  • the target data means data stored in the local memory accessed by the CPU instructed to return from the OS.
  • step S2701 If it is determined in step S2701 that reconfiguration is in progress (step S2701: Yes), restoration of local memory and reconstruction of parity data are started (step S2702). On the other hand, even when it is determined that reconfiguration is not being performed (step S2701: NO), similarly, restoration of local memory and reconstruction of parity data are started (step S2704). As will be described later, in the case of step S2702, the data being reconstructed is restored using parity data, and then the process proceeds to the data saving unit 906. On the other hand, in the case of step S2704, since it is not necessary to handle the data being reconfigured, the processing directly proceeds to the processing of the data saving unit 906.
  • step S2702 the command receiving unit 904 starts restoring the data stored in the local memory (step S2703), and the restored data generating unit 905 causes the restored data to be generated.
  • the restoration data generation unit 905 first searches for unreconstructed parity data (step S2741) and reads the corresponding data (step S2702). Thereafter, the restoration data generation unit 905 generates restoration data using the data read in step S2742 (step S2743). The generation of the restored data in step S2743 is repeatedly executed until there is no unreconstructed parity data.
  • step S2701 if it is determined in step S2701 that the reconstruction is not in progress (step S2701: NO), the command receiving unit 904 starts restoring the data stored in the local memory (step S2701). S2704).
  • step S2704 unlike the process of step S27002, there is no data being reconstructed, and therefore the restoration data generation unit 905 does not generate restoration data.
  • step S2711 the command receiving unit 904 searches the unreconstructed data by the parity reconstructing unit 903 (step S2711).
  • the unreconstructed data in step S2711 means data among the data stored in each local memory that has not been reconstructed with parity data corresponding to the number of operating CPUs after the power is restored.
  • the parity generation unit 902 generates parity data for the unreconstructed data searched by the parity reconstruction unit 903.
  • the parity generation unit 902 reads corresponding data (step S2721), and generates parity data for restoring the corresponding data (step S2722). afterwards.
  • the parity generation unit 902 writes the generated parity data in the local memory of each CPU (step S2723), and ends a series of processing.
  • the data saving unit 906 starts the data saving process after the process of step S2702 or S2704 of the command receiving unit 904.
  • the data saving unit 906 first searches for unrecovered data in the local memory (step S2731). Thereafter, the data retrieved in step S2731 is restored to the local memory (step S2732). The data standby process described above is repeated until there is no unrecovered data.
  • FIG. 28 and 29 are explanatory diagrams showing the procedure of the return operation of CPU # 1.
  • the return instruction of CPU # 1 that has been stopped is issued, and power supply to CPU # 1 and local memory 1 is started. All data stored in the local memory 1 is once lost when the power is stopped. Therefore, when the local memory 1 is restored, the RAID controller 801 sequentially restores the data saved in the shared memory 104 into the local memory.
  • the RAID controller 801 first reads the DATA 21 from the shared memory 104 by the data saving unit 906 and returns it to the local memory 1. Thereafter, the parity data generation unit 902 generates parity data for restoring the data currently stored in each local memory.
  • the parity generation unit 902 uses the parity 11, 21, 21 using the DATA 11 stored in the local memory 0, the DATA 21 stored in the local memory 1, and the DATA 31 stored in the local memory 2. 31 is generated.
  • the generated parity data (Parity 11, 21, 31) is overwritten by the parity restructuring unit 903 at the position where the parity data (Parity 11, 31) in the local memory 3 is currently stored.
  • the RAID controller 801 similarly reads the data after DATA 11 from the shared memory 104 and stores it in the local memory 1. Thereafter, unreconstructed data may be processed.
  • non-reconfigured means data for which restoration data has not been generated in the shared memory 104 by parity data after the power supply is stopped. Data originally stored in the stopped local memory is reconfigured in the shared memory 104 by parity data. However, when the period from the power stop to the return is short, the return process may start in a state before all data is reconstructed in the shared memory 104.
  • FIG. 29 shows a case where the DATA 24 is not reconfigured in the shared memory 104. In the case of such non-reconstructed data, it cannot be simply read from the shared memory 104 and returned to the local memory 1. Therefore, the restored data generation unit 905 generates DATA 24 from the parity data.
  • the DATA 24 performs an exclusive OR operation on the DATA 14 stored in the local memory 0, the DATA 34 stored in the local memory 2, and the parity 14, 24, 34 stored in the local memory 3. Obtained by.
  • the parity data reconstructed after the power of the CPU is stopped is based on the parity 11 and 31 stored in the local memory 3 of FIG. 28 and two DATAs other than the local memory. The data that has been restored.
  • parity data that is restored by data stored in three local memories, such as Parities 14, 24, and 34 is stored, that is, parity data after stopping like data after DATA24. This means that there is data that has not been reconstructed.
  • the OS inputs an instruction for resuming power supply to the RAID controller 801.
  • the RAID controller 801 restores data and reconstructs parity data in response to an instruction from the OS by the command receiving unit 904.
  • the RAID controller 801 operates on the data restored to the shared memory 104 even when the local memory is accessed from another CPU while the power is stopped and the content of the data is updated.
  • the user is guided to perform the writing process (for details, see ⁇ Access during Stop> above). Therefore, only by restoring the data saved in the shared memory 104 to the local memory, the local memory immediately stores the data reflecting the latest update contents.
  • FIG. 30 is an explanatory diagram of an example of access to the local memory being restored. Depending on the contents and timing of processing executed by the multi-core processor 800, access to the local memory being restored may occur as shown in FIG. There is no problem when accessing data that has already been restored to local memory by the restoration process.
  • the RAID controller 801 detects the access from the CPU # 0, takes the request of the CPU # 0 in place of the local memory 1, and restores the actual target data to make it accessible.
  • FIG. 31 is a flowchart showing an access procedure by the RAID controller being restored.
  • the flowchart of FIG. 31 shows the difference in operation of the RAID controller 801 according to the access contents when an access to the local memory being restored occurs.
  • the memory access monitoring unit 901 starts processing with the detection of access to the local memory being restored as a trigger.
  • the memory access monitoring unit 901 first determines whether the detected access is a read process (step S3101). If it is determined in step S3101 that the detected access is a read process (step S3101: Yes), the memory access monitoring unit 901 determines whether the access destination data has been reconfigured (step S3102).
  • step S3102 If it is determined in step S3102 that the data is not reconfigured data (step S3102: No), the memory access monitoring unit 901 stores the data to be accessed from the parity data in the local memory because there is currently no data to be accessed. The restored data is restored (step S3103). On the other hand, if it is determined in step S3102 that the data has been reconfigured (step S3102: Yes), it means that the target data has been restored to the shared memory 104. Therefore, the memory access monitoring unit 901 reads data saved in the shared memory 104 (step S3104).
  • step S3101 If it is determined in step S3101 that the access is a read process, the target data is read by the process of step S3103 or S3104. Therefore, the memory access monitoring unit 901 returns data to the reading source CPU (step S3105) and ends the series of processing.
  • step S3101 determines that it is not a read process (step S3101: No)
  • the memory access monitoring unit 901 determines that the access detected this time is a write process. Therefore, the memory access monitoring unit 901 writes to the target local memory (step S3106) and ends the series of processes. Thereafter, since the data written in step S3106 becomes the latest data, the memory access monitoring unit 901 generates parity data for restoring the latest data and updates the current parity data (step). S3107).
  • the parity generation unit 902 When an instruction to update parity data is given in step S3107, the parity generation unit 902 generates parity data for restoring the latest data as described above.
  • the parity generation unit 902 first reads target data (step S3121).
  • the parity generation unit 902 generates parity data using the data read in step S3121 (step S3122). Finally, the parity generation unit 902 updates the corresponding parity data to the parity data generated in step S3122 (step S3123), and ends the series of processes.
  • step S ⁇ b> 3103 the restoration data generation unit 905 is the main subject of the data restoration process.
  • the restored data generation unit 905 starts a series of processes triggered by the process in step S3103.
  • the restoration data generation unit 905 first reads the corresponding data (parity data) (step S3111), and uses the read data to generate data stored in the local memory as restoration data (step S3112).
  • step S3112 The data generated in step S3112 is returned to the memory access monitoring unit 901 and used for the processing in step S3105.
  • the procedure of the read process and the write process to the local memory being restored will be described with a specific example.
  • FIGS. 32 to 34 are explanatory diagrams showing the procedure of the reading operation to the CPU # 1 being restored.
  • a read operation for each data stored in the local memory 1 accessed by CPU # 1 from CPU # 0 occurs.
  • the data of DATA 21 and 22 has been restored in the local memory 1. Therefore, the CPU # 0 refers to the local memory 1 when reading the DATA 21.
  • the memory access monitoring unit 901 of the RAID controller 801 detects the occurrence of a read operation by the CPU # 0.
  • the memory access monitoring unit 901 notifies the CPU # 0 and causes the data saving unit 906 to read the DATA 23 restored to the shared memory 104.
  • the RAID controller 801 when reading DATA 24 that has not been restored to either the local memory 1 or the shared memory 104, the RAID controller 801 first accesses the data being restored by the memory access monitoring unit 901. Detect that there is.
  • the restoration data generation unit 905 restores the DATA 24 using the DATA 13, DATA 33, and Parities 14, 24, 34 stored in the active local memory other than the local memory 1 (local memory 0, 2, 3).
  • the restored data is stored in the local memory 1 and read by the CPU # 0.
  • FIGS. 35 and 36 are explanatory diagrams showing the procedure of the write operation to the CPU # 1 being restored.
  • a write operation for each data stored in the local memory 1 accessed by CPU # 1 from CPU # 0 occurs.
  • the data of DATA 21 and 22 has been restored in the local memory 1. Therefore, the CPU # 0 accesses the local memory 1 as it is when writing to the DATA 21.
  • the memory access monitoring unit 901 of the RAID controller 801 detects the occurrence of the writing operation by the CPU # 0.
  • the parity generation unit 902 when the contents of DATA 21 are updated, the parity generation unit 902 generates new parity data and overwrites the current parity data so that the updated data can be restored.
  • the CPU # 0 performs the writing process to the local memory 1 as it is. Unlike the read process, in the case of the write process, the data contents are overwritten, so there is no need to restore the DATA 24.
  • the parity generation unit 902 When DATA 24 is newly written, the parity generation unit 902 generates new parity data so that the updated data can be restored, and overwrites the current parity data.
  • the processing content of the RAID controller 801 differs depending on whether it is a read process or a write process.
  • read processing if the data to be read is reconstructed data, it may be guided to simply read from the shared memory 104, but it is not reconstructed data In this case, it is necessary to generate restored data one by one and read it into the access source CPU.
  • the series of processes can be finished as it is. If the data itself is changed by the writing process, the latest parity data reflecting the writing process is generated and stored in the local memory of the operating CPU. Even if a power failure occurs, the latest data can be restored at high speed.
  • the power supply to the local memory is stopped when the power to the CPU is stopped, thereby reducing the power consumption.
  • the stored data is lost and cannot be restored.
  • the data restoration device 110 stores the parity data for restoring the data stored in each local memory in advance in the operating local memory. Therefore, even if the power of the CPU 1 is stopped and the power supply to the local memory 1 is suddenly interrupted, the data stored in the local memory 1 is lost, but the stored data is immediately stored. Can be restored.
  • the multi-core processor 800 in order to stop unnecessary CPUs and increase power efficiency, it is assumed that the power supply to each CPU is frequently stopped or restored. Therefore, there is a case where access to a local memory in a state where data restoration is incomplete is performed even before data restoration by parity data and reconstruction of parity data are completely completed.
  • the RAID controller 801 manages the current state of the target data. Therefore, it is possible to support appropriate and efficient access without an access error or data update omission by the CPU.
  • FIG. 37 is an explanatory diagram of a configuration example of a multi-core processor including an access monitoring bus.
  • a multi-core processor 3700 that does not include the local memory bus 102 is used in the second embodiment and the third embodiment.
  • Some multi-core processors do not include the local memory bus 102 as in the first embodiment due to design and structural restrictions.
  • an example of data restoration processing for a multi-core processor that does not include the local memory bus 102 as described above will be described.
  • the local memory bus 102 If the local memory bus 102 is not provided, it means that the local memories cannot access each other. That is, each CPU cannot grasp what kind of access is being performed by a CPU other than its own CPU.
  • the access controller bus 3701 is newly added to monitor the access to each local memory by the RAID controller 3800, update the parity data, and stop the local memory power supply. Enables data saving at the time.
  • FIG. 38 is a block diagram illustrating an internal configuration of the RAID controller according to the second embodiment.
  • the RAID controller 3800 performs the memory access monitoring unit 901 that monitors the update of the local memory, the parity generation unit 902 that generates the parity data, and the reconstruction of the parity data, as in the first embodiment.
  • a data saving unit 906 for saving the contents.
  • the RAID controller 3800 of the second embodiment includes a data restoration unit 907 that restores the contents of the local memory when the power is resumed, and a local memory operation information table 3801 that records the operation state of the local memory.
  • the local memory operation information table 3801 is a data table for managing the operation status of the CPUs # 0 to # 3. Therefore, either “operation” or “stop” information is set according to the operation status of the corresponding CPU.
  • FIG. 39 is a flowchart illustrating the operation procedure of the OS when the power is stopped in the second embodiment.
  • the flowchart of FIG. 39 shows the instruction contents output from the OS to the RAID controller 3800 and the procedure when any one of the CPUs in the multi-core processor 3700 is stopped.
  • the OS starts the operation with the decision to stop the power supply as a trigger.
  • the OS determines whether the current number of CPUs is equal to or less than a specified value (step S3901). If it is determined in step S3901 that the number of CPUs is not less than or equal to the specified value (step S3901: No), the OS determines whether the parity is being reconfigured (step S3902).
  • step S3902 If it is determined in step S3902 that the parity is being reconfigured (step S3902: Yes), the OS waits until the reconfiguration is completed (step S3903), and saves the contents of the register in the shared memory 104 (step S3902). S3904). If it is determined in step S3902 that the parity is not being reconfigured (step S3902: NO), the process proceeds to step S3904 without waiting in step S3903.
  • the OS flushes the cache (step S3905) and notifies the RAID controller 3800 that the target CPU is stopped (step S3906). Further, the OS notifies the other processor of the stop of the target CPU (step S3907), operates the power supply mechanism (step S3908), and completely stops the power supply to the target CPU. The process ends.
  • step S3901 determines whether the number of CPUs is equal to or less than the specified value (step S3901: Yes). If it is determined in step S3901 that the number of CPUs is equal to or less than the specified value (step S3901: Yes), the OS saves the contents of the register in the memory (step S3909) and saves the contents of the local memory in the memory (step S3909). Step S3910). Thereafter, the OS flushes the cache (step S3911), and proceeds to the process of step S3907.
  • the OS when the CPU of the multi-core processor 3700 is stopped and the supply of power to any of the operating local memories is stopped, first, the saving of registers is performed by a higher-level program such as the OS as usual. Perform a cache flush. Thereafter, the OS notifies the RAID controller 3800 of the stop of its own CPU without saving the contents of the local memory, and turns off the power.
  • the RAID controller 3800 is inquired about the current state. Then, after waiting for the reconstruction to finish, the CPU power is turned off. As described in the first embodiment, if the number of CPUs to be stopped increases, the area required for parity data per local memory increases as (data area size / number of operations).
  • the RAID controller 3800 is not used and is stored in the local memory as usual, in case the current data cannot be stored in the prepared parity data area.
  • a process of stopping the power supply after saving the data in the shared memory 104 is adopted. Below, the processing content of each function part at the time of the power supply stop mentioned above is each demonstrated.
  • FIG. 40 is a flowchart showing the operation procedure of the command receiving unit.
  • the flowchart of FIG. 40 shows the processing content executed by the command receiving unit 904 when the power is stopped.
  • the power stop is executed by a power stop command from the OS to the CPU. Therefore, in the RAID controller 3800, a series of operations is started by command reception by the command receiving unit 904.
  • the command receiving unit 904 starts an operation triggered by reception of some command.
  • the command receiving unit 904 analyzes the received command (step S4001).
  • the command receiving unit 904 updates the local memory operation information table 3801 while being saved (step S4002).
  • the command receiving unit 904 notifies the data saving unit 906 of the stopped local memory (step S4003), and ends a series of processing.
  • step S4001 if the command is an instruction to restore power (step S4001: power restoration), the command receiving unit 904 updates the local memory operation information table 3801 while it is stopped (step S4004). Further, the command receiving unit 904 notifies the data restoring unit 907 of the restored local memory (step S4005), and ends a series of processing.
  • FIG. 41 is a flowchart showing the operation procedure of the data saving unit in the second embodiment.
  • the flowchart of FIG. 41 shows the processing contents executed by the data saving unit 906 when the power is stopped.
  • the data saving unit 906 first sets the address to 0 (step S4101), and instructs the restoration data generation unit 905 about the local memory and address to be restored (step S4102). Further, the data saving unit 906 saves the data received from the restored data generation unit 905 in the shared memory 104 (step S4103).
  • the data saving unit 906 determines whether or not the number of CPUs after the stop is equal to or greater than a specified value (step S4104). If it is determined in step S4104 that the number of CPUs is equal to or greater than the specified value (step S4104: Yes), the data saving unit 906 notifies the parity reconstruction unit 903 of the location of the parity data used for restoration (step S4105).
  • step S4106 increments the address (step S4106), and determines whether saving of the data area is completed (step S4107). If it is determined in step S4104 that the number of CPUs is not equal to or greater than the specified value (step S4104: No), the data saving unit 906 proceeds to the process of step S4106 without performing the process of step S4105, and performs the addressing. Is incremented.
  • step S4107 the data saving unit 906 returns to the process of step S4102 until the saving of the data area is completed, and repeats the process for the address after the increment (step S4107: No loop).
  • step S4107 determines whether the number of CPUs after the stop is equal to or less than a specified value (step S4108). If it is determined in step S4108 that the number of CPUs is equal to or less than the specified value (step S4108: Yes), the data saving unit 906 notifies the parity reconstruction unit 903 of the saving completion (step S4109), and a series of processes Exit.
  • step S4108 If it is determined in step S4108 that the number of CPUs after the stop is not less than the specified value (step S4108: No), the data saving unit 906 ends the series of processes without performing the process of step S4109. To do.
  • FIG. 42 is a flowchart illustrating an operation procedure of the restoration data generation unit according to the second embodiment.
  • the flowchart of FIG. 42 shows the processing content executed by the restoration data generation unit 905 when the power is stopped.
  • the restoration data generation unit 905 first reads data corresponding to the designated restoration target (step S4201). Thereafter, the restoration data generation unit 905 generates restoration data (step S4202) and ends a series of processing.
  • FIG. 43 is a flowchart showing the operation procedure of the parity reconstruction unit.
  • the flowchart in FIG. 43 represents processing related to parity data according to the notification content by the parity reconstructing unit 903.
  • the parity reconstruction unit 903 can generate appropriate parity data and store the generated parity data in an appropriate location.
  • the parity reconstruction unit 903 starts the operation triggered by reception of some notification from another functional unit.
  • the parity reconstruction unit 903 there are three types of notifications received by the parity reconstruction unit 903: parity data generation notification, save completion notification, and restoration completion notification. Therefore, the operation content of the parity reconstruction unit 903 also changes depending on which notification is received.
  • the parity reconstruction unit 903 instructs the parity generation unit 902 about the notified parity location (step S4301). Thereafter, the parity reconstruction unit 903 writes the generated parity data (step S4302), and ends a series of processing.
  • the parity reconstructing unit 903 calculates an unreconfigured area from the number of operating local memories before and after the stop (step S4303). Furthermore, when the parity reconstruction unit 903 instructs the parity generation unit 902 about the location of the parity (step S4304), the parity reconstruction unit 903 writes the generated parity data (step S4305).
  • the parity reconstruction unit 903 determines whether there is unreconstructed data (step S4306). If it is determined in step S4306 that there is unreconstructed data (step S4306: Yes), the parity reconstructing unit 903 returns to the process in step S4304 and continues the process for the unreconstructed data.
  • step S4306 determines whether there is no unreconstructed data (step S4306: No)
  • the parity reconstructing unit 903 updates the local memory operation commission information table 3801 to stop (step S4307). A series of processing ends.
  • the parity rebuilding unit 903 calculates an unreconstructed area of the local memory that has been restored from the number of operating local memories (step S4308). Thereafter, the parity reconstruction unit 903 instructs the parity generation unit 902 about the location of the parity (step S4309), and writes the generated parity data (step S4310).
  • the parity reconstruction unit 903 determines whether there is unreconstructed data (step S4311). If it is determined in step S4311 that there is unreconstructed data (step S4311: Yes), the parity reconstructing unit 903 returns to the process of step S4309 and continues the process for the unreconstructed data.
  • step S4311 determines whether there is no unreconstructed data (step S4311: No). If it is determined in step S4311 that there is no unreconstructed data (step S4311: No), the parity reconstructing unit 903 updates the local memory operation information table 3801 to be in operation (step S4312). A series of processing ends.
  • FIG. 44 is a flowchart showing an operation procedure of the parity generation unit.
  • the flowchart in FIG. 43 represents the processing content executed by the parity generation unit 902.
  • the parity generation unit 902 first reads data corresponding to the instructed parity (step S4401). Thereafter, the parity generation unit 902 generates parity data (step S4402) and ends a series of processing.
  • the command receiving unit 904 first determines the local memory operation information according to the command information received by the command receiving unit 904.
  • the table 3801 is updated. Further, it instructs the data saving unit 906 to save the contents of the stopped local memory. If the number of active local memories after the stop is greater than or equal to the specified value, an instruction is also given to the parity reconstruction unit 903 to reconstruct parity data in parallel.
  • the parity reconstruction unit 903 reconstructs parity data corresponding to the data restored from the save area by the data restoration unit 907.
  • the parity data corresponding to the restored parity area of the local memory is reconstructed.
  • the data saving unit 906 and the parity reconstruction unit 903 save from the top of the data area of the local memory where the data saving unit 906 is stopped.
  • the data restoration unit 907 is used to restore the data, and then save the data to a predetermined save area.
  • the data restoration unit 907 reads the parity data for restoring the data instructed from the data saving unit 906 and the corresponding data from the operating local memory, and restores the stopped local memory data.
  • parity reconstruction unit 903 sequentially reconstructs parity data using the parity generation unit 902 in the parity data area that has been saved. When saving of all data areas of the stopped local memory is completed, parity data is sequentially generated for the remaining areas.
  • FIG. 45 is a flowchart illustrating the operation procedure of the OS when the power is restored in the second embodiment.
  • the flowchart of FIG. 45 shows the processing contents of the OS when the power of the stopped CPU in the multi-core processor 3700 is restored in the second embodiment.
  • step S4501 the OS determines whether the local memory of another processor is being saved. If it is determined in step S4501 that the local memory of another processor is being saved (step S4501: Yes), the OS enters a standby state until the saving is completed (step S4502).
  • the OS does not save the local memory of another processor (step S4501: No) or waits until the saving is completed (step S4502), and notifies the RAID controller 3800 of the return (step S4503). After that, the OS restores the contents of the processor register (step S4504).
  • the OS waits until the local memory is restored by the RAID controller 3800 (step S4505), and notifies the other processor of the return (step S4506). Thereafter, the OS resumes normal processing (step S4507) and ends a series of return processing.
  • the contents of the register are restored from the OS executed by the CPU whose power supply has been resumed. Further, since the OS notifies the RAID controller 3800 of its own restoration at the same time, it is possible to resume the process before the stop after waiting for the restoration by the RAID controller 3800 to be completed.
  • FIG. 46 is a flowchart showing the operation procedure of the data restoration unit.
  • FIG. 46 shows the contents of processing executed by the data return unit 907 when power is restored.
  • the data restoration unit 907 first checks the local memory operation information table 3801 (step S4601), and determines whether or not it is being saved (step S4602). If it is determined in step S4602 that the local memory operation information table 3801 is being saved (step S4602: YES), the data restoration unit 907 notifies the data saving unit 906 of the withdrawal (step S4603).
  • the data restoration unit 907 acquires the last saved address from the data saving unit 906 (step S4604), and then sets the address to 0 and the end address to the address obtained in step S4604 (step S4605).
  • step S4602 determines whether the data is not being saved (step S4602: NO)
  • the data restoration unit 907 sets the address to 0 and the end address to the final address of the data area (step S4606).
  • step S4606 When address setting is performed in step S4605 or step S4606, the data restoration unit 907 restores the saved data to the local memory (step S4607). Then, the data restoration unit 907 determines whether or not the number of restored CPUs is equal to or greater than a specified value (step S4608).
  • step S4608 If it is determined in step S4608 that the number of CPUs after restoration is equal to or greater than the specified value (step S4608: Yes), the data restoration unit 907 notifies the parity reconstruction unit 903 of parity data corresponding to the restored data (step S4608). S4609). Thereafter, the data restoration unit 907 increments the address (step S4610).
  • step S4608 determines whether the number of CPUs after restoration is not greater than or equal to the specified value (step S4608: No). If it is determined in step S4608 that the number of CPUs after restoration is not greater than or equal to the specified value (step S4608: No), the data restoration unit 907 proceeds to the process of step S4611 without performing the process of step S4609. To do.
  • step S4611 determines whether or not the end address has been reached. If the end address has not been reached in step S4611 (step S4611: NO), the data return unit 907 returns to step S4607 and performs processing for the incremented address.
  • step S4611 determines whether the number of CPUs after restoration is equal to or greater than a specified value (step S4612). If it is determined in step S4612 that the number of CPUs is equal to or greater than the specified value (step S4612: Yes), the data restoration unit 907 notifies the parity reconstruction unit 903 of the completion of restoration (step S4613), and a series of processes Exit. On the other hand, if it is determined in step S4612 that the number of CPUs is not equal to or greater than the specified value (step S4612: No), the data return unit 907 ends the series of processes without performing the process of step S4613.
  • the data restoration unit 907 determines that all data has been saved unless the restored local memory is referred to by referring to the local memory operation information table 3801. Therefore, the data restoration unit 907 restores the saved data to the local memory.
  • the data saving unit 906 refers to the local memory operation information table 3801. If there is unsaved data, the restored data generation unit 905 restores the data from the unprocessed parity data before reconstruction to the local memory, so that the data can be restored without omission.
  • Example 3 In the third embodiment, the configuration of the multi-core processor 3700 shown in FIG. 51 is used as in the second embodiment. However, unlike the second embodiment, save return information 4801 (see FIG. 48) for recording the save return status of the local memory is added to the RAID controller 3800. By recording the save / return status of the local memory in the save / return information 4801 and causing the memory access monitoring unit 901 to monitor both the reading process and the writing process, it is expected to speed up the data restoration to the local memory at the time of power recovery. it can.
  • FIG. 47 is a flowchart illustrating the operation procedure of the OS when the power is restored in the third embodiment.
  • the flowchart of FIG. 47 shows the instruction contents output from the OS to the RAID controller 4800 (see FIG. 37) and the procedure when any one of the CPUs in the multi-core processor 3700 is stopped.
  • the OS of the multi-core processor starts the operation with a return instruction from the power stop as a trigger.
  • the OS notifies the RAID controller 4800 of the return (step S4701).
  • the OS restores the register contents of the restored processor (for example, CPU # 1) (step S4702)
  • the OS notifies the other processors of the restoration (step S4703).
  • the OS resumes normal processing of the restored processor (step S4704), and ends a series of operations when the power is restored.
  • the OS when power is restored starts processing without waiting for the RAID controller 4800 to restore the contents of the local memory.
  • FIG. 48 is a block diagram illustrating an internal configuration of the RAID controller according to the third embodiment. As shown in FIG. 48, in the case of the third embodiment, the RAID controller 4800 has a configuration in which save return information 4801 is added to the RAID controller 3800 of the second embodiment.
  • the memory access monitoring unit 901 can monitor access to the returning local memory in addition to the monitoring process described in the second embodiment.
  • the RAID controller 4800 By monitoring the access to the local memory that is being restored, the RAID controller 4800, when there is a read to the local memory data before the restoration, the RAID controller 4800 restores the target data first and sets the value. Can return. Then, when there is a write, the RAID controller 4800 can update the parity data as usual and update the save / return information so as not to recover the target data.
  • FIG. 49 is a flowchart showing the operation procedure of the memory access monitoring unit.
  • the flowchart of FIG. 49 shows the processing contents executed by the memory access monitoring unit 901.
  • the memory access monitoring unit 901 starts the operation triggered by detection of access to any local memory. Then, the memory access monitoring unit 901 first confirms the target entry in the local memory operation information table 3801 (step S4901). Next, the memory access monitoring unit 901 determines whether or not the entry confirmed in step S4901 is being restored (step S4902).
  • step S4902 determines whether the confirmed entry is a write access to any local memory. Is determined (step S4903). If it is determined in step S4903 that the confirmed entry is a write access (step S4903: YES), the memory access monitoring unit 901 calculates the location of the corresponding parity data (step S4904).
  • the memory access monitoring unit 901 When the location of the parity data is calculated in step S4904, the memory access monitoring unit 901 notifies the parity generation unit 902 of the calculated location (step S4905). Thereafter, the memory access monitoring unit 901 writes the generated parity data in the local memory (step S4906), updates the save return information 4801 corresponding to the write data to return (step S4907), and ends the series of processing. .
  • step S4903 determines whether or not the result of confirming the save return information 4801 is a return state (step S4909).
  • step S4909 when the confirmed result is the return state (step S4909: Yes), the memory access monitoring unit 901 ends the series of processes. On the other hand, if the confirmed result is not the return state (step S4909: No), the memory access monitoring unit 901 determines that the current access is a read access and performs the subsequent processing.
  • the memory access monitoring unit 901 notifies the restoration data generation unit 905 of the read destination location (step S4910). Thereafter, the memory access monitoring unit 901 returns the restored data to the access source (step S4911), and writes the restored data to the local memory (step S4912). Therefore, the memory access monitoring unit 901 updates the corresponding standby return information 4801 to return (step S4913).
  • the memory access monitoring unit 901 determines whether or not the number of restored CPUs is equal to or greater than a specified value (step S4914). If it is determined in step S4914 that the number of CPUs is equal to or greater than the specified value (step S4914: Yes), the memory access monitoring unit 901 notifies the parity reconstruction unit 903 of parity data corresponding to the restored data (step S4915). ), A series of processing ends. On the other hand, if it is determined in step S4914 that the number of CPUs is not above the specified value (step S4914: No), the memory access monitoring unit 901 ends the series of processes as it is.
  • step S4902 determines whether the confirmed entry is a write access to any local memory. (Step S4916). If it is determined in step S4916 that the confirmed entry is a write access (step S4916: Yes), the memory access monitoring unit 901 calculates the location of the corresponding parity data (step S4917).
  • step S4917 When the location of the parity data is calculated in step S4917, the memory access monitoring unit 901 notifies the calculated location to the parity generation unit 902 (step S4918). Thereafter, the memory access monitoring unit 901 writes the generated parity data in the local memory (step S4919), and ends a series of processing. On the other hand, if it is determined in step S4916 that the confirmed entry is not a write access (step S4916: No), the memory access monitoring unit 901 ends the series of processes as it is.
  • FIG. 50 is a flowchart illustrating an operation procedure of the data saving unit according to the third embodiment.
  • the flowchart in FIG. 50 shows the processing contents executed by the data saving unit 906.
  • the data saving unit 906 first sets the address to 0 (step S5001), and instructs the restoration data generation unit 905 about the local memory and address to be restored (step S5002). Thereafter, the data saving unit 906 saves the data received from the restored data generation unit 905 in the shared memory 104 (step S5003).
  • the data saving unit 906 determines whether or not the number of CPUs after the stop is equal to or greater than a specified value (step S5004). If it is determined in step S5004 that the number of CPUs is equal to or greater than the specified value (step S5004: Yes), the data saving unit 906 notifies the parity reconstruction unit 903 of the location of the parity data used for restoration (step S5005). ).
  • step S5006 updates the corresponding save return information 4801 to save (step S5006) and increments the address (step S5007).
  • step S5004 determines whether the number of CPUs is not equal to or greater than the specified value.
  • step S5007 the data saving unit 906 determines whether saving of the data area is completed (step S5008), and when it is determined that saving is completed (step S5008: Yes). Further, it is determined whether or not the number of CPUs after the stop is equal to or less than a specified value (step S5009).
  • step S5008 If it is determined in step S5008 that the saving of the data area has not been completed (step S5008: No), the data saving unit 906 proceeds to the process of step S5002 and performs processing for the next address. I do.
  • step S5009 the data saving unit 906 notifies the parity reconstruction unit 903 of completion of saving (step S5010) when it is determined that the number of CPUs after the stop is equal to or less than the specified value (step S5009: Yes). A series of processing ends.
  • step S5009 when it is determined in step S5009 that the number of CPUs after the stop is not less than or equal to the specified value (step S5009: No), the data saving unit 906 ends the series of processes as it is.
  • FIG. 51 is a flowchart illustrating an operation procedure of the restoration data generation unit according to the third embodiment.
  • the flowchart of FIG. 51 shows the processing content executed by the restoration data generation unit 905 of the third embodiment.
  • the restoration data generation unit 905 first checks the local memory operation information table 3801 (step S5101). Thereafter, the restored data generation unit 905 sets the address to 0 and the end address to the final address of the data area (step S5102).
  • the restoration data generation unit 905 determines whether the operation information is being saved (step S5103). If it is determined in step S5103 that the operation information is being saved (step S5103: Yes), the restoration data generation unit 905 checks the target save return information 4801 (step S5104), and determines whether the target data is being saved. Is determined (step S5105).
  • step S5105 If it is determined in step S5105 that the target data is being saved (step S5105: YES), the process proceeds to step S5109. On the other hand, if it is determined in step S5105 that the target data is not being saved (step S5105: No), the restored data generation unit 905 restores the saved data to the local memory (step S5106), and then the restored data is restored. It is determined whether the number of CPUs is equal to or greater than a specified value (step S5107).
  • step S5103 when it is determined in step S5103 that the operation information is not being saved (step S5103: No), the restored data generation unit 905 proceeds to the process of step S5106 and restores the saved data to the local memory. To do.
  • step S5107 If it is determined in step S5107 that the number of CPUs after restoration is greater than or equal to the specified value (step S5107: Yes), the restoration data generation unit 905 notifies the parity reconstruction unit 903 of parity data corresponding to the restored data. (Step S5108). If it is determined in step S5107 that the number of CPUs after restoration is not equal to or greater than the specified value (step S5107: No), the restoration data generation unit 905 proceeds to processing in step S5109.
  • the restoration data generation unit 905 increments the address (step S5109), and determines whether the incremented address has reached the end address (step S5110). If the end address has not been reached in step S5110 (step S5110: No), the restoration data generation unit 905 returns to the process of step S5103 and performs the process for the next address.
  • step S5110 determines whether or not the number of CPUs after restoration is equal to or greater than a specified value (step S5111).
  • step S5111: Yes If it is determined that the number of CPUs is equal to or greater than the specified value (step S5111: Yes), the restoration data generation unit 905 notifies the parity reconstruction unit 903 of the completion of restoration (step S5112) and ends a series of processing. . If it is determined in step S5111 that the number of CPUs is not equal to or greater than the specified value (step S5111: No), the restoration data generation unit 905 ends the series of processes as it is.
  • the memory access monitoring unit 901 and the data saving unit 906 update the saving return information 4801 when saving data. Therefore, the data return unit 907 can return the unrecovered information with reference to the save return information 4801 and update the save return information. Therefore, it is possible to prevent a situation in which erroneous data is saved, and to realize a faster power stop compared to the second embodiment.
  • FIG. 52 is an explanatory diagram showing a power comparison example when the data restoration processing is employed.
  • the number of CPUs that are arranged in advance and the number of CPUs that are operated simultaneously are various, and the power efficiency varies greatly depending on the usage situation.
  • frequent power ON / OFF often does not provide a sufficient power saving effect due to the generation of the save time considering the save time of the data stored in the local memory.
  • FIG. 52 a simple comparison result of power consumption between the multi-core processor to which the data restoration processing according to the present embodiment is applied and other multi-core processors is illustrated.
  • a multi-core processor having four CPUs will be described.
  • FIG. 52 shows the power when the power of the local memory is not turned off, the interruption shows the power when the power is turned off by the conventional method (supplying power until data is saved), and the lower part shows the power of the present embodiment. Electric power when such data restoration processing is used is shown. Further, when the data restoration processing according to the present embodiment is used, it is set to generate parity data if three or more CPUs are operating.
  • the data restoration processing according to the present embodiment is applied to a multicore processor in which the number of CPUs is relatively small and the number of operating CPUs changes frequently, it is expected to provide a system with high power efficiency. it can.
  • the data restoration device As described above, according to the data restoration program, the data restoration device, and the data restoration method according to the present embodiment, even if the data stored in the volatile memory is lost, the parity stored in advance is stored. The data stored in the volatile memory can be restored by the data. Accordingly, it is not necessary to save the contents of the local memory in advance when the power of the local memory is stopped, so that the power stop operation of the local memory can be speeded up.
  • the above technique further creates parity data according to the number of volatile memories that can be stored when the number of volatile memories in operation changes. Therefore, even in an environment where the number of processors changes frequently, parity data with an appropriate configuration can be created.
  • the data restored to the shared memory can be automatically restored to the volatile memory. Further, when the processor is started, data that has not been restored in the shared memory is reconfigured using parity data and then restored to the volatile memory. Therefore, even if the processor is frequently stopped or restarted, the data stored in the volatile memory and once lost can be restored without leaving.
  • the processor when the volatile memory accessed by the operating processor is stopped, the processor stores the data depending on whether or not the data stored in the volatile memory is reconfigured.
  • the access destination can be changed. If the data stored in the volatile memory has not been reconfigured, the data to be accessed is reconfigured to support access by the processor. Therefore, even if there is a stopped processor among the multi-core processors, other operating processors can access desired data in the same procedure as usual without considering the operating state of the other processors.
  • the method for saving data stored in the volatile memory can be changed according to the number of operating processors.
  • the number of operating processors is large and parity data is stored in volatile memory and the processing speed of each processor is not reduced, a save process using parity data is used to stop the power supply quickly. Realize. If the number of processors in operation is small and the capacity of volatile memory is compressed by storing parity data, and the processing speed of the processor may be reduced, the conventional method is not used. Save the data by Therefore, since the most efficient method is used according to the number of operating processors, the processing speed of the multi-core processor can be kept within an assumed value.
  • the data restoration method described in the present embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.
  • the data restoration program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer.
  • the data restoration program may be distributed via a network such as the Internet.
  • the data restoration apparatus 110 described in the present embodiment is a PLD (Programmable) such as a standard cell or a specific application IC (hereinafter simply referred to as “ASIC”) such as a structured ASIC (Application Specific Integrated Circuit). It can also be realized by Logic Device. Specifically, for example, the functions (stop detection unit 601 to return unit 606) of the above-described data restoration device 110 are defined by HDL description, and the HDL description is logically synthesized and given to the ASIC or PLD. The restoration device 110 can be manufactured.
  • ASIC Application Specific Integrated Circuit

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)
  • Power Sources (AREA)

Abstract

　データ復元装置（１１０）は、ステップＳ１の処理としてＣＰＵ＃１およびローカルメモリ１への電力供給が停止した後、冗長データからローカルメモリの内容を共有メモリ（１０４）上に復元する。具体的には、ローカルメモリ１に格納されていたＤＡＴＡ２がＤＡＴＡ１、ＤＡＴＡ３およびＰａｒｉｔｙ１によって復元され共有メモリ（１０４）内の待避領域＃１に格納される。ステップＳ１の復元後、データ復元装置（１１０）は、ステップＳ２の処理として、稼働中のＣＰＵの数に応じてパリティデータを再構築する。

Description

データ復元プログラム、データ復元装置およびデータ復元方法
　この発明は、プロセッサに搭載された揮発性メモリに格納されているデータを復元するデータ復元プログラム、データ復元装置およびデータ復元方法に関する。
　従来より、マルチコアプロセッサにおける低消費電力技術として、プロセッサ全体の負荷が軽いときには、現在利用されていないプロセッサの電源を切って消費電力を削減する手法が開示されている（たとえば、下記特許文献１，２参照）。
　さらに、各ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）がローカルメモリを搭載したマルチコアプロセッサでは、プロセッサの電源を切るときに同時に各ＣＰＵと対になっているローカルメモリの電源も切る手法と、プロセッサの電源を切ってもローカルメモリの電源は入れたままにする手法が用いられている。近年では、特にローカルメモリの容量増加に伴ってローカルメモリの消費電力が増加する傾向にあるため、電力効率の観点から、プロセッサの電源切断に伴ってローカルメモリの電源も落とす手法が広く採用されている。
　一般的にプロセッサ内部のレジスタやローカルメモリは、揮発性メモリによって構成されており、電源が供給されている状態でなければ内部の情報が保持されない。そこで、通常は、オペレーティングシステム（以下、「ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）」と呼ぶ）等により、電源を切る前にプロセッサのレジスタおよびローカルメモリに格納されているデータを、共有メモリなどの電源が切られないプロセッサ外部の記憶装置に待避する処置が施される。
　ローカルメモリなど、揮発性メモリに格納されていたデータを、共有メモリに待避させることによって、ＣＰＵ内のキャッシュをフラッシュしてデータが消えたとしても問題なく利用することができる。そして、電源が再投入された時に、ＯＳ等により待避されたデータが共有メモリから読み出され、ローカルメモリに復元される。
　また、最近では、ハードディスクなどの格納データの安全性を保持するための技術として広く活用されているＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙｓ　ｏｆ　Ｉｎｅｘｐｅｎｓｉｖｅ　Ｄｉｓｋｓ）技術を、ローカルメモリの待避に応用することで電源切断によるデータの消滅を回避する例も開示されている（たとえば、下記特許文献３，４）。
　ＲＡＩＤ技術を利用した場合、ローカルメモリに格納されているデータを他のメモリに分散して格納する。したがって、ＣＰＵの電源停止に伴ってローカルメモリの電源が停止されても、他のメモリに格納されたデータを利用して、消去されてしまったデータを復元することができる。
特開昭６２－１９８９４９号公報 特開平９－２１２４１６号公報 特開２００５－１０８２２４号公報 特開２００９－５０７３２４号公報
　しかしながら、近年の微細化技術の進歩に伴ってローカルメモリの容量が増加し、レジスタやキャッシュに比べて待避にかかる時間の増加が著しく、電力効率の悪化に大きく影響する可能性が高くなっている。たとえば、レジスタやキャッシュの容量は、数十～数百バイト、もしくは数十キロバイトであるが、ローカルメモリの容量は数百キロバイトに及ぶものも多い。したがって、ローカルメモリに格納されているデータを待避させるまでの電力量を考慮すると、低消費電力技術を採用したにもかかわらず、十分な効果が得られないという問題があった。
　また、上述のような揮発性メモリ内のデータの待避処理に対する解決策として、ＲＡＩＤ技術が挙げられているが、ＲＡＩＤによってデータを分散するハードディスクとマルチコアプロセッサのローカルメモリとの構成の違いが考慮されていないため、十分な効果を得るに至ってない。
　本来、ＲＡＩＤ技術によるデータの復元はハードディスクドライブの故障を前提とした技術である。具体的には、従来のＲＡＩＤ技術では１つか２つのＨＤＤ（Ｈａｒｄ　ｄｉｓｋ　Ｄｒｉｖｅ）が停止することを想定してデータを分散させたり、復元用の冗長データを生成したりする構成になっている。
　一方、マルチコアプロセッサにおける電源制御の場合、複数のローカルメモリの電源を停止することがある。したがって、従来のＲＡＩＤ技術の延長ではローカルメモリの電源制御に対応して消滅したデータを復元するような運用は困難であった。
　本開示技術は、上述した従来技術による問題点を解消するため、揮発性メモリに格納されたデータの待避を待たずに高速な電源停止を可能にするデータ復元プログラム、データ復元装置、データ復元方法を提供することを目的とする。
　上述した課題を解決し、目的を達成するため、本開示技術は、揮発性メモリおよび当該揮発性メモリにアクセスするプロセッサを複数搭載したマルチコアプロセッサにアクセス可能なコンピュータによって、前記マルチコアプロセッサ内の複数のプロセッサの中のいずれかのプロセッサへの停止指示を検出し、前記停止指示が検出されると、前記停止指示を受けたプロセッサ以外の稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、前記停止指示を受けたプロセッサがアクセスする揮発性メモリに格納されていたデータを、前記稼働中のプロセッサ群がアクセス可能な共有メモリ内に復元する。
　本データ復元プログラム、データ復元装置およびデータ復元方法によれば、揮発性メモリに格納されたデータの待避を待たずに高速な電源停止を可能にするという効果を奏する。
本実施の形態にかかるデータ復元処理の一例を示す説明図である。 ＲＡＩＤ技術を利用したマルチコアプロセッサの構成例を示す説明図である。 ＲＡＩＤ１の運用を示す説明図である。 ＲＡＩＤ５の運用を示す説明図である。 データ復元装置のハードウェア構成を示すブロック図である。 データ復元装置の機能的構成を示すブロック図である。 データ復元装置によるデータ復元処理の手順を示すフローチャートである。 ＲＡＩＤコントローラを備えたマルチコアプロセッサの構成例を示すブロック図である。 実施例１におけるＲＡＩＤコントローラの内部構成例を示すブロック図である。 通常時の動作例を示す説明図である。 通常時のＲＡＩＤコントローラの動作手順を示すフローチャートである。 電源停止時の動作例を示す説明図である。 実施例１における電源停止時のＯＳの動作手順を示すフローチャートである。 電源停止時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。 ＣＰＵ＃１の停止動作の手順（その１）を示す説明図である。 ＣＰＵ＃１の停止動作の手順（その２）を示す説明図である。 ＣＰＵ＃１の停止動作の手順（その３）を示す説明図である。 ＣＰＵ＃１の停止動作の手順（その４）を示す説明図である。 電源停止中のローカルメモリへのアクセス例を示す説明図である。 電源停止中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。 電源停止中のローカルメモリへの読込手順（その１）を示す説明図である。 電源停止中のローカルメモリへの読込手順（その２）を示す説明図である。 電源停止中のローカルメモリへの書込手順（その１）を示す説明図である。 電源停止中のローカルメモリへの書込手順（その２）を示す説明図である。 電源復帰時の動作例を示す説明図である。 実施例１における電源復帰時のＯＳの動作手順を示すフローチャートである。 電源復帰時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。 ＣＰＵ＃１の復帰動作の手順（その１）を示す説明図である。 ＣＰＵ＃１の復帰動作の手順（その２）を示す説明図である。 復元中のローカルメモリへのアクセス例を示す説明図である。 復元中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。 復元中のＣＰＵ＃１への読込動作の手順（その１）を示す説明図である。 復元中のＣＰＵ＃１への読込動作の手順（その２）を示す説明図である。 復元中のＣＰＵ＃１への読込動作の手順（その３）を示す説明図である。 復元中のＣＰＵ＃１への書込動作の手順（その１）を示す説明図である。 復元中のＣＰＵ＃１への書込動作の手順（その２）を示す説明図である。 アクセス監視バスを備えたマルチコアプロセッサの構成例を示す説明図である。 実施例２におけるＲＡＩＤコントローラの内部構成を示すブロック図である。 実施例２における電源停止時のＯＳの動作手順を示すフローチャートである。 コマンド受信部の動作手順を示すフローチャートである。 実施例２におけるデータ待避部の動作手順を示すフローチャートである。 実施例２における復元データ生成部の動作手順を示すフローチャートである。 パリティ再構築部の動作手順を示すフローチャートである。 パリティ生成部の動作手順を示すフローチャートである。 実施例２における電源復帰時のＯＳの動作手順を示すフローチャートである。 データ復帰部の動作手順を示すフローチャートである。 実施例３における電源復帰時のＯＳの動作手順を示すフローチャートである。 実施例３におけるＲＡＩＤコントローラの内部構成を示すブロック図である。 メモリアクセス監視部の動作手順を示すフローチャートである。 実施例３におけるデータ待避部の動作手順を示すフローチャートである。 実施例３における復元データ生成部の動作手順を示すフローチャートである。 データ復元処理を採用した場合の電力比較例を示す説明図である。
　以下に添付図面を参照して、この発明にかかるデータ復元プログラム、データ復元装置およびデータ復元方法の好適な実施の形態を詳細に説明する。
　図１は、本実施の形態にかかるデータ復元処理の一例を示す説明図である。図１に示すように、マルチコアプロセッサ１００は、複数のＣＰＵ（たとえば、ＣＰＵ＃０～ＣＰＵ＃３）を備えたプロセッサ群である。マルチコアプロセッサ１００は、複数のＣＰＵ以外に、電源１０１と、ローカルメモリバス１０２と、共有メモリバス１０３とを備えている。
　電源１０１は、各ＣＰＵおよび各ＣＰＵがアクセスするローカルメモリに電力を供給する。また、電源１０１は、ＯＳからの指示に応じて、指定されたＣＰＵおよびローカルメモリのみの電力の供給を停止することが可能である。同様に、電源１０１は、ＯＳからの指示に応じて、指定されたＣＰＵおよびローカルメモリのみの電力の供給を復帰させることもできる。また、各ＣＰＵはＯＳによって制御されるが、ＣＰＵが停止中は対応するＯＳも停止中になる。したがって、各ＯＳは自ＣＰＵの電源のＯＦＦを制御すると共に、他ＣＰＵの電源のＯＮを制御する。
　ローカルメモリバス１０２は、各ＣＰＵとローカルメモリとのアクセスを可能にするバスである。また、各ＣＰＵは、ローカルメモリバス１０２を経由して他のプロセッサのローカルメモリにもアクセスすることができる。
　共有メモリバス１０３は、マルチコアプロセッサ１００と共有メモリ１０４とのアクセスを可能にするバスである。共有メモリ１０４は、不揮発性メモリもしくは、常時電力が供給されるデータ消失の恐れのないメモリである。
　本実施の形態の場合、図１のように、上述したような構成のマルチコアプロセッサ１００に、データ復元装置１１０を追加することによって、ＣＰＵと共にローカルメモリへの電力供給が停止されても、ローカルメモリ内のデータを復元することができる。
（従来の電源停止・始動手順）
　本実施の形態にかかるデータ復元処理を説明する前に、従来のマルチコアプロセッサの電源停止および始動の手順について説明する。
　従来の電源停止時では、マルチコアプロセッサ１００にデータ復元装置１１０が備わっておらず、停止対象となるＣＰＵのＯＳ（たとえば、ＣＰＵ＃０のＯＳ）が電源停止処理を開始する。ＯＳは、まず、停止対象のＣＰＵのレジスタとローカルメモリ内のデータを共有メモリ１０４に待避させる。次に、ＯＳは、キャッシュの内容を共有メモリ１０４に書き戻す。続いて、ＯＳは、他のＣＰＵのＯＳへ電力停止を通知する。最後に、ＯＳから電源１０１へ電力供給の停止指示が行われ、電源が切られる。
　次に、従来の電源始動時では、稼働中のＣＰＵのＯＳ（たとえば、ＣＰＵ＃１のＯＳ）が停止中のＣＰＵの電源復帰処理を開始する。ＯＳは、まず、電源１０１に対して復帰させるＣＰＵへの電力供給の始動指示を行い、電源を入れる。次に、ＯＳは、共有メモリ１０４に待避したレジスタおよびローカルメモリのデータを復帰させたＣＰＵのレジスタおよびローカルメモリ内に復元する。
　以上説明したように、従来の電源停止の場合には、ローカルメモリ内のデータを共有メモリ１０４に待避するまで、ローカルメモリへの電力供給の停止を待機しなければならなない。同様に、電源始動の場合にも、電源停止の際に共有メモリ１０４にローカルメモリ内のデータが待避されている場合には、すべてのデータをローカルメモリ内に復元するまで、ＣＰＵは通常の動作に移行することはできない。
（ＲＡＩＤ技術）
　図２は、ＲＡＩＤ技術を利用したマルチコアプロセッサの構成例を示す説明図である。従来の電源停止の際のデータの待避時間を省略するための対策案として、ＲＡＩＤ技術が利用されることがある。具体的には、電源停止時にローカルメモリのデータを回避しなくても、冗長化したデータから停止されたＣＰＵのローカルメモリに格納されていたデータを復元することができる。
　図２に例示したマルチコアプロセッサ２００の場合、ＣＰＵ＃１が停止しても、ローカルメモリ０に格納されたＤＡＴＡ１と、ローカルメモリ２に格納されたＤＡＴＡ３と、ローカルメモリ３に格納されたＰａｒｉｔｙ１によってＤＡＴＡ２を復元することができる。同様に、ＤＡＴＡ６についても、ローカルメモリ０，２，３にそれぞれ格納されたＤＡＴＡ５、Ｐａｒｉｔｙ２、ＤＡＴＡ４によって復元することができる。
　図３は、ＲＡＩＤ１の運用を示す説明図であり、図４は、ＲＡＩＤ５の運用を示す説明図である。ＲＡＩＤ技術とは、複数のハードディスクドライブ（以下、「ＨＤＤ」と呼ぶ）を仮想的な１台のＨＤＤとして運用する技術である。ＲＡＩＤ技術の中には図３に示したＲＡＩＤ１のように、１つのデータ（たとえばデータＡ）を、ＲＡＤＩコントローラによって、複数のＨＤＤにそれぞれ格納するミラーリングがある。
　また、図４に示したＲＡＤＩ５のように、格納用のデータ（たとえばデータＡ～Ｆ）の他に、冗長データ（パリティデータ（たとえばＰａｒ１やＰａｒ２））を分散して格納する。いずれかのＨＤＤが破損したとしても、パリティデータを利用して半損したデータを復元することができる。
　具体的には、下記のように破損したＨＤＤ以外のＨＤＤに格納されている各データ同士の排他的論理和を求めることによって破損したＨＤＤに格納されていたデータを復元する。
　Ｐａｒ１　＝ＡｘｏｒＢｘｏｒＣ
　Ａ　　　　＝ＢｘｏｒＣｘｏｒＰａｒ１
　Ｂ　　　　＝ＡｘｏｒＢｘｏｒＰａｒ１
　Ｃ　　　　＝ＢｘｏｒＣ　ｘｏｒＰａｒ１
　Ｐａｒ２　＝ＤｘｏｒＥｘｏｒＦ
　Ｄ　　　　＝ＥｘｏｒＦｘｏｒＰａｒ２
　Ｅ　　　　＝ＤｘｏｒＦｘｏｒＰａｒ２
　Ｆ　　　　＝ＢｘｏｒＣｘｏｒＰａｒ２
　上述したいずれの手法もＨＤＤに格納するデータを冗長化することによって予期せぬＨＤＤの故障からデータを保護することができる。したがって、従来より、ＲＡＩＤ５やＲＡＩＤ５に類似したＲＡＩＤ６を利用してＣＰＵのローカルメモリなど揮発性メモリに格納されたデータを保護する手法があった。
　ところが、マルチコアプロセッサ１００のように、複数のローカルメモリに格納されたデータをＲＡＩＤ５の手法によって分散すると、複数のＣＰＵが停止中になってしまうような事態には対応できない可能性が高い。
　ＲＡＩＤ技術の場合、複数のＨＤＤの中の１つのＨＤＤが故障した場合に残りのＨＤＤに格納されたデータを利用して故障したＨＤＤに格納されたデータを復元する。したがって、同じ手法をマルチコアプロセッサに適用すると、複数のＣＰＵの電源が停止された場合には、ローカルメモリに格納されたデータを復元することができない。
　ＲＡＩＤ５の手法におけるパリティデータを多数作成して複数のＣＰＵが停止してもローカルメモリに格納されていたデータを復元することも可能ではあるが、ローカルメモリにおけるパリティデータの比率が増し、ＣＰＵが使用できる領域を縮小させてしまう。
　そこで、本実施の形態では、ローカルメモリへの電力供給が停止後に、停止したローカルメモリの内容をパリティデータから復元して、共有メモリ１０４に待避すると共に、稼働中のローカルメモリの構成に合わせて、新たなパリティデータを再構築する。
　図１に戻って説明すると、データ復元装置１１０は、ＣＰＵ＃１およびローカルメモリ１への電力供給が停止した後、冗長データからローカルメモリの内容を共有メモリ１０４上に復元する（ステップＳ１）。具体的には、ローカルメモリ１に格納されていたＤＡＴＡ２がＤＡＴＡ１、ＤＡＴＡ３およびＰａｒｉｔｙ１によって復元され共有メモリ１０４内の待避領域＃１に格納される。なお、実際には続いて、ローカルメモリ１に格納されていたＤＡＴＡ６についても同様に、ＤＡＴＡ５、ＤＡＴＡ３、ＤＡＴＡ４およびＰａｒｉｔｙ２によって復元されるが、ここでは説明を省略する。
　ステップＳ１の復元後、データ復元装置１１０は、稼働中のＣＰＵの数に応じてパリティデータを再構築する（ステップＳ２）。すなわち、ＣＰＵ＃１が停止する前は、４つのＣＰＵのローカルメモリを利用して、各ローカルメモリに格納されているデータをそれぞれ復元可能なパリティデータが格納されていた。ところが、ＣＰＵ＃１が停止してしまった。そこで、ＣＰＵ＃１の停止後は、稼働中の３つのＣＰＵのローカルメモリを利用して、各ローカルメモリに格納されているデータをそれぞれ復元可能なパリティデータを生成（再構築）して、ローカルメモリに、それぞれ格納する。
　パリティデータの再構築後であれば、さらに別のＣＰＵのローカルメモリの電源を止めても、再構築後のパリティデータからデータを復元できるため、同様の手順を行うことで複数のローカルメモリの電源停止に対応できる。したがって、ローカルメモリの電源停止時に事前にローカルメモリの内容を待避しておく必要がなくなるため、ローカルメモリの電源停止動作を高速化することができる。
　以下に、図１に例示したような高速な電源停止を実現するためのデータ復元装置１１０の具体的な構成例および処理手順について説明する。
（データ復元装置のハードウェア構成）
　図５は、データ復元装置のハードウェア構成を示すブロック図である。図５において、データ復元装置１１０は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）５０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ　Ｍｅｍｏｒｙ）５０２と、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）５０３と、磁気ディスクドライブ５０４と、磁気ディスク５０５と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）５０６と、を備えている。また、各構成部はバス５００によってそれぞれ接続されている。
　ここで、ＣＰＵ５０１は、データ復元装置の全体の制御を司る。ＲＯＭ５０２は、ブートプログラムや、データ復元処理を実現するためのデータ復元プログラムなどの各種プログラムを記憶している。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。磁気ディスクドライブ５０４は、ＣＰＵ５０１の制御にしたがって磁気ディスク５０５に対するデータのリード／ライトを制御する。磁気ディスク５０５は、磁気ディスクドライブ５０４の制御で書き込まれたデータを記憶する。なお、記憶媒体として図５の例では磁気ディスク５０５を挙げたが、光ディスクや半導体メモリなど他の媒体を利用してもよい。
　インターフェース（以下、「Ｉ／Ｆ」と略する。）５０６は、所定の通信規格に応じたバスによって、マルチコアプロセッサ内の各ＣＰＵや、各ＣＰＵがアクセスする揮発性メモリ（ローカルメモリ）、また、共有メモリ１０４との相互通信を実現する。
（データ復元装置の機能的構成）
　図６は、データ復元装置の機能的構成を示すブロック図である。データ復元装置１１０は、停止検出部６０１と、復元部６０２と、作成部６０３と、格納部６０４と、始動検出部６０５と、復帰部６０６と、を含む構成である。この制御部となる機能（停止検出部６０１～復帰部６０６）は、具体的には、たとえば、図５に示したＲＯＭ５０２、ＲＡＭ５０３、磁気ディスク５０５などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０６により、その機能を実現する。
　停止検出部６０１は、ＯＳなどの上位プログラムからプロセッサへの停止指示を検出する機能を有している。具体的には、停止検出部６０１は、マルチコアプロセッサ６００内の複数のプロセッサ（プロセッサ０～プロセッサｎ）の中のいずれかのプロセッサへの停止指示を検出する。なお、検出結果は、ＲＡＭ５０３、磁気ディスク５０４などの記憶領域に記憶される。
　復元部６０２は、電力の供給が停止した揮発性メモリに格納されていたデータを共有メモリ１０４に復元する機能を有する。具体的には、復元部６０２は、検出部６０１によって停止指示が検出されると、停止指示先のプロセッサ以外の稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、揮発性メモリに格納されていたデータを復元する。そして、復元部６０２は、復元したデータを稼働中のプロセッサ群がアクセス可能な共有メモリ１０４内に格納する。復元されたデータは、一時的に、ＲＡＭ５０３、磁気ディスク５０５などの記憶領域に記憶される。
　作成部６０３は、新たなパリティデータを作成する機能を有する。具体的には、作成部６０３は、復元部６０２によってデータの復元が実行された後に、稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されているデータを復元するパリティデータを作成する。なお、作成されたパリティデータは、ＲＡＭ５０３、磁気ディスク５０５などの記憶領域に記憶される。
　格納部６０４は、作成されたパリティデータを稼働中のプロセッサの揮発性メモリに格納する機能を有する。具体的には、格納部６０４は、作成部６０３によって作成されたパリティデータを、それぞれ稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納する。
　このとき、格納部６０４は、パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納する。たとえば、揮発性メモリ１に格納されたデータを復元するパリティデータは、揮発性メモリ１以外の稼働中のプロセッサの揮発性メモリに格納される。
　なお、作成部６０３は、複数のプロセッサの中のいずれかのプロセッサの揮発性メモリに新たにデータが追加または新たなデータに更新されると、新たなデータを復元するパリティデータを作成する。すなわち、揮発性メモリに格納されているデータが更新されると、その都度、最新のデータを復元するためのパリティデータを作成する。
　したがって、格納部６０４は、作成部６０３によって作成されたパリティデータを、それぞれ稼働中のプロセッサ群がアクセスする揮発性メモリのうち、新たなデータが追加または新たなデータに更新された揮発性メモリ以外の揮発性メモリに格納する。
　始動検出部６０５は、上位プログラムからのプロセッサへの指示を検出する機能を有する。具体的には、始動検出部６０５は、複数のプロセッサの中の停止中のプロセッサへの電力供給の始動を検出する。なお、検出結果は、ＲＡＭ５０３、磁気ディスク５０５なの記憶領域に記憶される。
　復帰部６０６は、電力供給が開始されたプロセッサの揮発性メモリに、待避中のデータを復帰する機能を有する。具体的には、復帰部６０６は、始動検出部６０５によって電力供給の始動が検出された場合、共有メモリ１０４に復元されたデータを、電力供給の始動が検出されたプロセッサがアクセスする揮発性メモリに格納する。
　また、復元部６０２によるデータの復元中に、始動検出部６０５によって、電力供給の始動が検出された場合、揮発性メモリに格納されていたデータのうち、共有メモリ１０４に復元されていないデータがある。これらのデータについて、復帰部６０６は、稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータを用いて復元して復帰させる。
　作成部６０３は、上述した復帰部６０６によってデータが復元された場合には、稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されているデータを復元するパリティデータを作成する。また、格納部６０４は、作成部６０３によって作成されたパリティデータを、パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納する。すなわち、揮発性メモリ１に格納されていたデータを復元するパリティデータは、揮発性メモリ１以外の稼働中の揮発性メモリ群に格納される。
　また、データ復元装置１１０は、上述した停止検出部６０１や始動検出部６０５の検出機能に加えて、いずれかのプロセッサから揮発性メモリに格納されているデータに対する読込要求を検出する読込検出機能を用意してもよい。
　具体的には、読込検出機能によって、読込要求が検出されたデータが格納されている揮発性メモリが稼働中でない場合、データ復元装置１１０は、データが共有メモリ１０４に格納されていることをデータの読込を実行するプロセッサに通知する。通知を受けたプロセッサは、通知に基づいて所望のデータが格納されていない揮発性メモリではなく、実際に所望のデータが格納されている共有メモリ１０４に格納されているデータを読み込むことができる。
　また、停止中の揮発性メモリに格納されていたデータに対して、共有メモリ１０４に復元する前に読込要求が発生した場合がある。上述のような場合、データ復元装置１１０は、復元部６０２の機能を利用して、パリティデータに基づいて、停止中の揮発性メモリに格納されていたデータを復元する。さらに、データ復元装置１１０は、復元したデータの格納先を、データの読込を実行するプロセッサに通知することによって、所望するデータを読み込ませることができる。
　またデータ復元装置１１０は、さらに、稼働中のプロセッサ数に応じて、本実施の形態にかかるデータ復元処理と、従来のデータ待避処理とのいずれかを選択的に適用させてもよい。稼働中のプロセッサ数が極端に少なくなってしまうと、稼働中の揮発性メモリの容量に占めるパリティデータ量の割合が増してしまう。すなわち、プロセッサが本来の処理に利用できる揮発性メモリの容量が小さくなり、プロセッサの機能低下を招いてしまい、結果として電力効率が悪化してしまう。
　そこで、データ復元装置１１０を適用するマルチコアプロセッサ６００のプロセッサの総数や、揮発性メモリの容量に応じて、あらかじめ定めたＣＰＵ数の規定値をしきい値として、しきい値を基準に本実施の形態にかかるデータ復元処理と、従来のデータ待避処理とのいずれを利用するか自動的に判断する構成にすることもできる。しきい値を利用した判断を行うことによって、データ復元装置１１０は、マルチコアプロセッサ６００内の各プロセッサの稼働状況に応じて、最も電力効率のよい動作となるように支援することができる。
　具体的には、たとえば、マルチコアプロセッサ６００によって実行中のＯＳによって、稼働中のプロセッサの数がしきい値以上か否かを判断する処理を実行させる。そして、プロセッサが、マルチコアプロセッサ６００のいずれかのプロセッサへの停止指示を受け付けると、稼働中のプロセッサの数がしきい値以上と判断された場合、ＯＳは、停止指示が受け付けられたプロセッサおよび当該プロセッサがアクセスする揮発性メモリへの電力供給の停止指示を電源１０１に出力して、即座に電力供給を停止する。
　すなわち、データ復元装置１１０では、本実施の形態にかかるデータ復元処理を実行させるため、揮発性メモリへの電力供給が停止しても、格納されていたデータは、共有メモリ１０４内に復元される。
　一方、稼働中のプロセッサの数がしきい値以上ではないと判断された場合、パリティデータ量が大きくなってしまう。そこで、ＯＳは、従来技術と同様に、揮発性メモリ内のデータを共有メモリ１０４に待避させるまで電力供給の停止を待つ。
　具体的には、ＯＳは、マルチコアプロセッサ６００に、稼働中のプロセッサの数がしきい値以上ではないと判断された場合、停止指示が受け付けられたプロセッサの揮発性メモリに格納されているデータを共有メモリ１０４に転送する。また、ＯＳは、上述の転送によって揮発性メモリに格納されているデータが共有メモリ１０４に転送された後、揮発性メモリへの電力供給の停止指示を電源１０１に出力する。
（データ復元処理の手順）
　図７は、データ復元装置によるデータ復元処理の手順を示すフローチャートである。図７のフローチャートは、データ復元装置１１０が、プロセッサに対する停止指示を受けた際に、揮発性メモリに格納されていたデータを自動的に復元して共有メモリ１０４に格納するまでの手順を示している。図７の各処理を実行することによって、データ復元装置１１０を備えたマルチコアプロセッサ６００は、停止指示を受けたプロセッサの揮発性メモリに格納された内容の待避処理を待つことなく、即座に電源を停止することができる。
　図７において、データ復元装置１１０は、まず、停止検出部６０１によって停止指示を検出したか否かを判断する（ステップＳ７０１）。ステップＳ７０１において、停止指示を検出したと判断された場合（ステップＳ７０１：Ｙｅｓ）、データ復元装置２０は、ステップＳ７０４の処理に移行し、停止対象となる揮発性メモリに格納されていたデータの復元処理を行う。
　なお、ステップＳ７０１において、停止指示を検出していないと判断された場合（ステップＳ７０１：Ｎｏ）、データ復元装置１１０は、ＯＳが現在稼働中の揮発性メモリに対して新たなデータを格納するか否かを判断する（ステップＳ７０２）。ステップＳ７０２によって、新たなデータを格納するか否かは、マルチコアプロセッサ６００を動作させる上位のプログラム（ここではＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ））からの書込指示を受けたか否かに応じて判断される。
　ステップＳ７０２において、新たなデータを格納すると判断された場合（ステップＳ７０２：Ｙｅｓ）、データ復元装置１１０は、作成部６０３によって、揮発性メモリに格納された新たなデータを復元するためのパリティデータを作成し、格納部６０４によって稼働中のプロセッサの揮発性メモリに格納される（ステップＳ７０３）。
　一方、ステップＳ７０１によって停止指示を検出したと判断された場合、データ復元装置１１０は、復元部６０２によって、パリティデータを用いて停止したプロセッサの揮発性メモリに格納されていたデータを共有メモリ１０４に復元する（ステップＳ７０４）。
　ステップＳ７０３，Ｓ７０４の処理が完了した後、もしくは、ステップＳ７０２において、新たなデータを格納しないと判断された場合（ステップＳ７０２：Ｎｏ）、データ復元装置１１０は、始動検出部６０５によって始動指示を検出したか否かを判断する（ステップＳ７０５）。
　ステップＳ７０５によって始動指示を検出した場合（ステップＳ７０５：Ｙｅｓ）、データ復元装置１１０は、復帰部６０６によって、共有メモリ１０４にステップＳ７０４によって復元したデータを、始動したプロセッサの揮発性メモリに復帰する（ステップＳ７０６）。一方、ステップＳ７０５によって始動指示を検出しなかった場合（ステップＳ７０５：Ｎｏ）、ステップＳ７０６の処理を行わずに、ステップＳ７０７の処理に移行する。
　その後、データ復元装置１１０は、ＯＳなどの上位システムから終了指示を受けたか否かを判断する（ステップＳ７０７）。データ復元装置１１０は、終了指示を受けなければ（ステップＳ７０７：Ｎｏ）、ステップＳ７０１～Ｓ７０６までの処理を繰り返す。そして、ステップＳ７０７において、データ復元装置１１０は、終了指示を受けると（ステップＳ７０７：Ｙｅｓ）、そのまま一連の処理を終了する。
　以上説明したように、データ復元装置１１０を用意することによって、マルチコアプロセッサ６００のいずれかのプロセッサとその揮発性メモリへの電力供給を停止させても揮発性メモリに格納されていたデータを復元することができる。したがって、従来のように、揮発性メモリ内のデータの待避を考慮することなく、高速にＣＰＵを停止して消費電力を大幅に削減することができる。また、データ復元装置１１０は、マルチコアプロセッサ６００において、稼働中のプロセッサ数に応じて電源停止時のデータ待避の手法を自動的に選択させることもできる。
　次に、上述したようなデータ復元処理を実現するデータ復元装置１１０の具体的な適用例として、データ復元装置１１０の機能を、ＲＡＩＤコントローラによって実現する実施例１～３について詳しく説明する。
（実施例１）
　図８は、ＲＡＩＤコントローラを備えたマルチコアプロセッサの構成例を示すブロック図である。実施例１では、ＲＡＩＤコントローラ８０１によって、データ復元装置１１０の機能を実現する。マルチコアプロセッサ８００のＲＡＩＤコントローラ８０１は、ローカルメモリバス１０２によって、各ＣＰＵとローカルメモリとが接続されている。また、各ＣＰＵもローカルメモリバス１０２を経由して他のＣＰＵのローカルメモリにアクセスできる構成になっている。
　図９は、実施例１におけるＲＡＩＤコントローラの内部構成例を示すブロック図である。ＲＡＩＤコントローラ８０１は、メモリアクセス監視部９０１と、パリティ生成部９０２と、パリティ再構築部９０３と、コマンド受信部９０４と、復元データ生成部９０５と、データ待避部９０６とを備えている。
　メモリアクセス監視部９０１は、ＣＰＵからローカルメモリへのアクセスを監視する。また、パリティ生成部９０２は、ローカルメモリに格納されたデータを復元するためのパリティデータを生成する。
　パリティ再構築部９０３は、ローカルメモリに書込があった場合に対応するパリティデータを更新する。コマンド受信部９０４は、ＯＳから出力されたコマンドを受信してコマンドの内容に応じた処理を実行する。復元データ生成部９０５は、パリティデータを利用して、停止されたローカルメモリに格納されていたデータを共有メモリ１０４内に復元する。データ待避部９０６は、電源停止時にローカルメモリに格納されていたデータを一時的に待避させる。なお、上述した各機能部の詳細な処理手順は後述する。
　なお、ローカルメモリのデータ領域は、通常のデータ領域として利用する領域と、パリティデータ領域に分割されている。また、現在稼働しているローカルメモリがＮ個有り、現在稼働しているローカルメモリの中でｍ番目のローカルメモリのアドレスｘの値を書き換えたとすると、（Ｎ×ｘ＋ｍ）／（Ｎ－１）…（１）式の整数部分が同一となるｘ，ｍの組み合わせの場所からデータを読み込んでパリティデータを生成する。
　また、（Ｎ×ｘ＋ｍ）／（Ｎ－１）２…（２）式の整数部分をｙ、余りをｋとすると、Ｎ－１－ｋ番目のローカルメモリのｙ番目のアドレスにパリティデータを書き込む。なお、パリティデータの生成には幾つか手法が知られているが、ここで説明する実施例１～３では、ＲＡＩＤ５技術と同様に排他論理和によりパリティデータを生成する。
　具体的には、パリティ生成部９０２では、上記（１），（２）式から、現在稼働しているローカルメモリ数がＮでｋ番目のローカルメモリのｙ番目のアドレスにパリティデータを再構築する。そして、上記（１），（２）式から逆算して、Ｎ×ｘ＋ｍ＝（Ｎ×ｘ＋ｍ）／（Ｎ－１）を満たすｍ，ｘの組み合わせのローカルメモリ／アドレスからデータを読み込んで排他論理和によりパリティデータを生成する。
＜通常時の動作＞
　図１０は、通常時の動作例を示す説明図である。まず、ＲＡＩＤコントローラ８０１の通常時の動作について説明する。図１０のように、通常時ＲＡＩＤコントローラ８０１は、稼働中のいずれかのＣＰＵからローカルメモリへのアクセスが発生すると、アクセス内容に応じて、パリティデータを生成する。
　具体的には、図１０のようにＣＰＵ＃０からローカルメモリ０への書込処理が行われると、書込処理によって、ローカルメモリ０のデータの内容が更新される。このとき、メモリアクセス監視部９０１は、ＣＰＵ＃０からのアクセスを検出する。そして、検出されたアクセスが書込処理であったため、パリティ生成部９０２は、書込処理後のデータを復元するパリティデータ（Ｐａｒｉｔｙ１１，２１，３１）を生成する。生成されたパリティデータは、パリティ生成部９０２によって、ＣＰＵ＃３のパリティデータ領域に格納される。
　図１１は、通常時のＲＡＩＤコントローラの動作手順を示すフローチャートである。通常時とは、マルチコアプロセッサが稼働中のＣＰＵのみの動作であり、ＣＰＵの停止や、停止中のＣＰＵの復帰などの動作が発生していない状態を意味する。
　図１０において、ＲＡＩＤコントローラ８０１は、まずメモリアクセス監視部９０１において、ローカルメモリへの書込を検出する（ステップＳ１１０１）。その後、ＲＡＩＤコントローラ８０１は、パリティ生成部９０２において、まず、対応するデータを読み込み（ステップＳ１１０２）、パリティデータを生成する（ステップＳ１１０３）。その後、ＲＡＩＤコントローラ８０１は、対応するパリティデータを更新し（ステップＳ１１０４）、一連の処理を終了する。
　以上説明したように、通常時ＲＡＩＤコントローラ８０１では、ローカルメモリへの書込が検出された場合には、その都度、書き込まれたデータを復元するためのパリティデータを生成し、生成されたパリティデータを最新のパリティデータとして更新しておく。したがって、どのようなタイミングで電源停止が発生しても、最新データを復元することができる。
＜電源停止時の動作＞
　図１２は、電源停止時の動作例を示す説明図である。図１２に例示したように、稼働中のＣＰＵの中のいずれか１つのＣＰＵの電源停止が行われた場合、停止されたＣＰＵのローカルメモリも、格納されているデータを待避することなく、即座に電力供給が停止し、電源停止状態となる。ＲＡＩＤコントローラ８０１は、電力供給停止後に、稼働中のローカルメモリに格納されている冗長データから電源停止したローカルメモリに格納されていたデータの内容を共有メモリ１０４上に復元する（ステップＳ１２０１）。
　図１３は、実施例１における電源停止時のＯＳの動作手順を示すフローチャートである。図１３のフローチャートは、電源停止時にＯＳからＲＡＩＤコントローラ８０１へ出力される指示内容と、その手順を表している。
　図１３において、ＯＳはまず、稼働中のＣＰＵ数が規定値以下か否かを判断する（ステップＳ１３０１）。ステップＳ１３０１において、稼働中のＣＰＵ数が規定値以下でないと判断された場合（ステップＳ１３０１：Ｎｏ）、ＯＳは、パリティデータが再構築中か否かを判断する（ステップＳ１３０２）。
　ステップＳ１３０２において、パリティが再構築中であると判断された場合（ステップＳ１３０２：Ｙｅｓ）、ＯＳは、再構築中が完了するまで待ち（ステップＳ１３０３）、レジスタの内容を共有メモリ１０４に待避させる（ステップＳ１３０４）。なお、ステップＳ１３０２において、パリティが再構築中ではないと判断された場合（ステップＳ１３０２：Ｎｏ）、ステップＳ１３０３によって待機することなく、ステップＳ１３０４の処理に移行する。
　その後、ＯＳは、キャッシュをフラッシュして（ステップＳ１３０５）、ＲＡＩＤコントローラ８０１に対象となるＣＰＵの停止を通知する（ステップＳ１３０６）。さらに、ＯＳは、他のプロセッサに対象となるＣＰＵの停止を通知し（ステップＳ１３０７）、電源機構を操作して（ステップＳ１３０８）、対象となるＣＰＵへの電力供給を完全に停止させ、一連の処理を終了する。
　一方、ステップＳ１３０１において、ＣＰＵ数が規定値以下であると判断された場合（ステップＳ１３０１：Ｙｅｓ）、ＯＳは、レジスタの内容を共有メモリ１０４に待避し（ステップＳ１３０９）、ローカルメモリの内容を共有メモリ１０４に待避する（ステップＳ１３１０）。その後、ＯＳは、キャッシュをフラッシュし（ステップＳ１３１１）、ステップＳ１３０７の処理に移行する。
　図１４は、電源停止時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。図１４のフローチャートは、電源停止時にＲＡＩＤコントローラ８０１内の各機能部がどのような処理を行うかを表している。
　図１４において、ＲＡＩＤコントローラ８０１は、コマンド受信部９０４が電源停止コマンドの受信をトリガに動作を開始する。まず、コマンド受信部９０４は、停止後のＣＰＵ数が規定値以下か否かを判断する（ステップＳ１４０１）。ステップＳ１４０１において、ＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ１４０１：Ｎｏ）、コマンド受信部９０４は、停止したＣＰＵのローカルメモリの内容の待避を開始して（ステップＳ１４０２）、パリティデータの再構築を開始する（ステップＳ１４０３）。
　ステップＳ１４０２によってローカルメモリの内容の待避が開始されると、データ待避部９０６は、未待避のデータを検索する（ステップＳ１４１１）。復元データ生成部９０５は、ステップＳ１４１１の検索結果を利用して、対応するデータを読み込み（ステップＳ１４２１）、復元データを生成する（ステップＳ１４２２）。復元データ生成部９０５によって復元データが生成されると、データ待避部９０６は、共有メモリ１０４に復元データを待避する（ステップＳ１４１２）。データ待避部９０６による待避処理は、未待避のデータがなくなるまで繰り返し行われる。
　一方、ステップＳ１４０１において、ＣＰＵ数が規定値以下であると判断された場合（ステップＳ１４０１：Ｙｅｓ）、ステップＳ１４０２と同様に停止したＣＰＵのローカルメモリの内容の待避を開始する（ステップＳ１４０４）。ステップＳ１４０４の場合は、ステップＳ１４０２とは異なり、従来の待避処理を行う。すなわち、ステップＳ１４０４の待避処理が完了するまで、ローカルメモリへの電力供給が継続される。
　一方、ステップＳ１４０２の待避処理が開始された場合、ステップＳ１４０３の処理後に、パリティ再構築部９０３によって未再構成データを検索する（ステップＳ１４３１）。その後、パリティ生成部９０２によって、対応するデータを読み込み（ステップＳ１４４１）、パリティデータを生成する（ステップＳ１４４２）。その後、パリティ生成部９０２によって、生成されたパリティデータを各ローカルメモリへ書き込む（ステップＳ１４４３）。上述したパリティデータの生成は、未再構成データがなくなるまで、繰り返し行われる。
　図１５～１８は、ＣＰＵ＃１の停止動作の手順を示す説明図である。図１５では、ローカルメモリ１が停止された状態を表している。ローカルメモリ１の停止に伴い、ローカルメモリ１に格納されたデータを復元しなければならない。また、同時に、稼働中のローカルメモリが停止されても格納されていたデータを復元可能にするため、パリティデータを再構築しなければならない。
　復元データ生成部９０５では、ＤＡＴＡ１１，３１およびＰａｒｉｔｙ１１，２１，３１によってＤＡＴＡ２１が復元される。復元されたデータはデータ待避部９０６によって共有メモリ１０４に格納される。また、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ１１，３１）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ３に格納される。
　引き続き、図１６のように、復元データ生成部９０５では、ＤＡＴＡ１２，４１およびＰａｒｉｔｙ４１，１２，２２によってＤＡＴＡ２２が復元される。復元されたデータはデータ待避部９０６によって共有メモリ１０４に格納される。また、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ４１，１２）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ２に格納される。
　引き続き、図１７のように、復元データ生成部９０５では、ＤＡＴＡ３２，４３およびＰａｒｉｔｙ２３，３３，４３によってＤＡＴＡ２３が復元される。復元されたデータはデータ待避部９０６によって共有メモリ１０４に格納される。また、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ３２，４２）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ０に格納される。
　最後に、図１８のように、停止されたローカルメモリに格納されたＤＡＴＡ２Ｎまでの処理が終了すると、復元データ生成部９０５の処理は終了し、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ３Ｎ，４Ｎ）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ０に格納される。
　上述の図１３～１８にて説明したように、電源停止時にはＯＳからＲＡＩＤコントローラ８０１へ電力供給の停止に関する指示が入力される。ＲＡＩＤコントローラ８０１は、コマンド受信部９０４によってＯＳからの指示に応答してデータの復元やパリティデータの再構築を行う。したがって、ローカルメモリ内のデータの待避を待たずに済むため、高速な電源停止が可能となる。
＜電源停止中のアクセス＞
　図１９は、電源停止中のローカルメモリへのアクセス例を示す説明図である。マルチコアプロセッサ８００によって実行する処理の内容によっては図１９のように電源停止中のローカルメモリに対するアクセスが発生することがある。アクセスとは、データの読込を行う読込処理と、データの書込を行う書込処理とを意味する。
　読込処理、書込処理いずれの場合も実際のアクセス先であるローカルメモリ１は停止中であり、対象となるデータは存在しない。そこで、ＲＡＩＤコントローラ８０１は、ＣＰＵ＃０からのアクセスを検出して、ＣＰＵ＃０の要求をローカルメモリ１の代わりに受け持って、実際に対象となるデータが存在するメモリ（たとえば共有メモリ１０４）へ誘導する。
　図２０は、電源停止中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。図２０のフローチャートは、停止中のローカルメモリへのアクセスが発生した際のアクセス内容に応じたＲＡＩＤコントローラ８０１の動作の違いを表している。
　図２０において、メモリアクセス監視部９０１は、停止中のローカルメモリへのアクセスの検出をトリガにして処理を開始する。メモリアクセス監視部９０１は、まず、検出したアクセスが読込処理か否かを判断する（ステップＳ２００１）。ステップＳ２００１において、検出したアクセスが読込処理であると判断された場合（ステップＳ２００１：Ｙｅｓ）、メモリアクセス監視部９０１は、アクセス先のデータが再構成済みか否かを判断する（ステップＳ２００２）。
　ステップＳ２００２において、再構成済みのデータでないと判断された場合（ステップＳ２００２：Ｎｏ）、メモリアクセス監視部９０１は、現状ではアクセス対象となるデータが存在しないため、パリティデータからローカルメモリに格納されていたデータを復元する（ステップＳ２００３）。一方、ステップＳ２００３において、再構成済みのデータであると判断された場合（ステップＳ２００２：Ｙｅｓ）、対象となるデータは共有メモリ１０４に復元済みであることを意味する。したがって、メモリアクセス監視部９０１は、共有メモリ１０４に待避したデータを読み込む（ステップＳ２００４）。
　ステップＳ２００１によってアクセスが読込処理と判断された場合には、ステップＳ２００３もしくはＳ２００４の処理によって対象となるデータが読み込まれる。したがって、メモリアクセス監視部９０１は、読込元ＣＰＵにデータを返して（ステップＳ２００５）、一連の処理を終了する。
　なお、ステップＳ２００１において、読込処理ではないと判断された場合（ステップＳ２００１：Ｎｏ）、メモリアクセス監視部９０１は、今回検出したアクセスは書込処理であると判断する。したがって、メモリアクセス監視部９０１は、共有メモリ１０４の待避領域へ対象となるデータを書き込んで（ステップＳ２００６）、一連の処理を終了する。アクセスが書込処理であった場合には、今回のアクセスによってデータ自体が更新されてしまう。したがって、読込処理のようにローカルメモリに格納されていたデータを復元する必要はない。
　また、上述したように、今回検出されたアクセスが読込処理であり、対象となるデータが再構成されていなかった場合には、ステップＳ２００３によってデータが復元されている。ステップＳ２００３において、データを復元する際の処理の主体は復元データ生成部９０５となる。
　具体的に説明すると、復元データ生成部９０５は、ステップＳ２００３の処理がトリガとなり、一連の処理を開始する。復元データ生成部９０５は、まず、対応するデータ（パリティデータ）を読み込み（ステップＳ２０１１）、読み込んだデータを利用して、ローカルメモリに格納されていたデータを復元データとして生成する（ステップＳ２０１２）。ステップＳ２０１２によって生成されたデータは、メモリアクセス監視部９０１に返され、ステップＳ２００５の処理に利用される。以下に、停止中のローカルメモリへの読込処理と書込処理との手順について具体例を挙げて説明する。
　図２１，２２は、電源停止中のローカルメモリへの読込手順を示す説明図である。図２１では、ＣＰＵ＃０から停止中のＣＰＵ＃１のローカルメモリ１へ読込処理の要求が発生している。ＣＰＵ＃０は、ローカルメモリ１に格納されている（実際には格納されていた）データを順に読み出すため、まず、先頭のＤＡＴＡ２１を読込処理の対象のデータとしている。
　メモリアクセス監視部９０１は、ＣＰＵ＃０からの読込処理を検出すると、ＤＡＴＡ２１が共有メモリ１０４に再構成済みのデータか否かを判断する。図２１の例では、ローカルメモリ１のＤＡＴＡ２１～２３までが共有メモリ１０４に再構成済みのデータである。したがって、メモリアクセス監視部９０１は、ＣＰＵ＃０に共有メモリ１０４に格納されているＤＡＴＡ２１を読み込ませる。
　ＣＰＵ＃０は、ローカルメモリ１に格納されていたデータをＤＡＴＡ２１から順番に読み込んでいくが、図２２に例示したように、対象データがＤＡＴＡ２４以降となると共有メモリ１０４から読み込むことができない。そこで、ＲＡＩＤコントローラ８０１は、復元データ生成部９０５によって、再構成が済んでいないデータを復元する。
　たとえば、図２２のように、ＤＡＴＡ２４を復元するには、復元データ生成部９０５は、稼働中のＣＰＵ＃０，２，３のローカルメモリ０，２，３に格納されているＤＡＴＡ１４，３４およびＰａｒｉｔｙ１４，２４，３４の排他的論理和演算を満たすデータを生成することによって、ＤＡＴＡ２４を得ることができる。ＤＡＴＡ２５以降についても同様の手順で復元することができる。メモリアクセス監視部９０１は、復元データ生成部９０５によって復元されたデータをＣＰＵ＃０に読み込ませることによって、停止中のローカルメモリ１であっても稼働中と遜色なくデータを読み込むことができる。
　図２３，２４は、電源停止中のローカルメモリへの書込手順を示す説明図である。図２３では、ＣＰＵ＃０から停止中のＣＰＵ＃１のローカルメモリ１への書込処理の要求が発生している。ＣＰＵ＃０は、ローカルメモリ１に格納されている（実際には格納されていた）データの中のアドレス順に順次書き込むため、まず、先頭のＤＡＴＡ２１を書込処理の対象のデータとしている。
　メモリアクセス監視部９０１は、ＣＰＵ＃０からの書込処理を検出すると、共有メモリ１０４にＤＡＴＡ２１を書き込ませる。その後、図２４ように対象となるデータがＤＡＴＡ２４に移行しても、メモリアクセス監視部９０１は、図２３の処理と同様に共有メモリ１０４にＤＡＴＡ２４を書き込ませる。
　読込処理とは異なり、書込処理の際には、書込後のデータが最新のデータとなるため、共有メモリ１０４に対象となるデータが再構成済みか否かを判断する必要はない。いずれのデータであっても、メモリアクセス監視部９０１は、ＣＰＵ＃０に対して一様に共有メモリ１０４に書き込むように誘導すればよい。
　以上説明したように、停止中のローカルメモリへのアクセスが発生した場合には、アクセスが、読込処理であるのか書込処理であるのかに応じてＲＡＩＤコントローラ８０１の処理内容が異なる。読込処理であった場合には、さらに、読込処理の対象となるデータが再構成済みのデータであれば単純に共有メモリ１０４から読み込むように誘導すればよいが、再構成済みのデータではない場合には、逐一復元データを生成して、アクセス元のＣＰＵに読み込ませる必要がある。
　しかしながら、読込処理が完了した後は、データ自体に変更はないためそのまま一連の処理を終わらせることができる。また、書込処理によってデータ自体の変更があった場合でも、稼働中のＣＰＵのローカルメモリには影響しないためパリティデータを再構築する必要はない。
＜電源復帰時の動作＞
　図２５は、電源復帰時の動作例を示す説明図である。次に、一旦、電源停止されたＣＰＵに再度電力が供給される電源復帰時の動作について説明する。図２５のように、ＣＰＵ＃１およびローカルメモリ１の電力供給が再開すると、ＲＡＩＤコントローラ８０１は、まず、共有メモリ１０４に待避されていたデータを、ローカルメモリ１に復元する（ステップＳ２５０１）。
　続いて、ＲＡＩＤコントローラ８０１は、電源復帰後の稼働中のＣＰＵの数に応じてパリティデータを再構築する（ステップＳ２５０２）。ＣＰＵ＃１が復帰したことによって、ＣＰＵ＃０～３が稼働中となった。したがって、各ＣＰＵのローカルメモリは、自ローカルメモリに格納しているデータを復元するためのパリティデータを、自ローカルメモリ以外の３つのローカルメモリのパリティ領域に格納する。
　図２６は、実施例１における電源復帰時のＯＳの動作手順を示すフローチャートである。図２６のフローチャートは、停止中のＣＰＵが他のＣＰＵからの復帰指示を受けて、通常動作の処理を再開するまでの手順を示している。
　図２６において、ＯＳは、停止中のＣＰＵ以外の他のＣＰＵにおける電源復帰の決定処理をトリガに動作を開始する。まずＯＳは、上述の他のＣＰＵから停止中のＣＰＵの電源機構を操作させる（ステップＳ２６０１）。
　その後、ＯＳは、電源復帰の対象ＣＰＵにおいて、ＲＡＤＩコントローラ８０１に復帰を通知する（ステップＳ２６１１）。続いて、ＯＳは、レジスタの内容を復元し（ステップＳ２６１２）、他のプロセッサ（他のＣＰＵ）に復帰を通知する（ステップＳ２６１３）。その後、ＯＳは、復帰させたＣＰＵの処理を再開させることによって（ステップＳ２６１４）、一連の復帰処理を終了する。
　図２７は、電源復帰時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。図２７のフローチャートは、ＯＳから電源復帰指示を受けた際のＲＡＩＤコントローラ８０１の動作を表している。
　図２７において、ＲＡＩＤコントローラ８０１は、コマンド受信部９０４において、ＯＳから出力された電源復帰に関するコマンドの受信をトリガに処理を開始する。まず、コマンド受信部９０４は、復帰処理の対象となるデータが再構成中か否かを判断する（ステップＳ２７０１）。なお、対象となるデータとはＯＳから復帰指示がなされたＣＰＵがアクセスするローカルメモリに格納されていたデータを意味する。
　ステップＳ２７０１において、再構成中であると判断された場合（ステップＳ２７０１：Ｙｅｓ）、ローカルメモリの復元とパリティデータの再構築を開始する（ステップＳ２７０２）。一方、再構成中でないと判断された場合も（ステップＳ２７０１：Ｎｏ）、同様に、ローカルメモリの復元とパリティデータの再構築を開始する（ステップＳ２７０４）。後述するように、ステップＳ２７０２の場合は、再構成中のデータについては、パリティデータを利用して復元してから、データ待避部９０６の処理に移行する。一方、ステップＳ２７０４の場合には、再構成中のデータを扱う必要がないため、そのままデータ待避部９０６の処理に移行する。
　ステップＳ２７０２の処理の後、コマンド受信部９０４は、ローカルメモリに格納されていたデータの復元を開始し（ステップＳ２７０３）、復元データ生成部９０５によって復元データの生成を実行させる。
　復元データ生成部９０５では、まず、未再構築のパリティデータを検索し（ステップＳ２７４１）、対応するデータを読み込む（ステップＳ２７０２）。その後、復元データ生成部９０５は、ステップＳ２７４２において読み込んだデータを用いて復元データを生成する（ステップＳ２７４３）。ステップＳ２７４３による復元データの生成は未再構築のパリティデータがなくなるまで繰り返して実行される。
　コマンド受信部９０４の処理に戻り、ステップＳ２７０１において再構成中ではないと判断された場合（ステップＳ２７０１：Ｎｏ）、コマンド受信部９０４は、ローカルメモリに格納されていたデータの復元を開始する（ステップＳ２７０４）。上述したように、ステップＳ２７０４の場合、ステップＳ２７００２の処理と異なり、再構成中のデータは存在しないため、復元データ生成部９０５による復元データの生成は行われない。
　また、コマンド受信部９０４は、ステップＳ２７０２およびＳ２７０４が開始されると、パリティ再構築部９０３によって未再構成データの検索が行われる（ステップＳ２７１１）。ステップＳ２７１１における未再構成データとは、各ローカルメモリに格納されているデータの中の、電源復帰後に稼働中のＣＰＵ数に応じたパリティデータの再構築が済んでいないデータを意味する。
　続いて、パリティ生成部９０２によって、パリティ再構築部９０３によって検索された未再構成データを対象としたパリティデータの生成が行われる。まず、パリティ生成部９０２は、対応するデータを読み込み（ステップＳ２７２１）、対応するデータを復元するためのパリティデータを生成する（ステップＳ２７２２）。その後。パリティ生成部９０２は、生成したパリティデータを、各ＣＰＵのローカルメモリに書き込んで（ステップＳ２７２３）、一連の処理を終了する。
　また、データ待避部９０６では、コマンド受信部９０４のステップＳ２７０２もしくはＳ２７０４の処理の後、データ待避処理が開始される。データ待避部９０６は、まず、ローカルメモリに未復旧のデータを検索する（ステップＳ２７３１）。その後、ステップＳ２７３１によって検索されたデータをローカルメモリへ復旧する（ステップＳ２７３２）。上述したデータ待機処理は、未復旧のデータがなくなるまで繰り返し行われる。
　図２８，２９は、ＣＰＵ＃１の復帰動作の手順を示す説明図である。図２８では、停止中であったＣＰＵ＃１の復帰指示が行われ、ＣＰＵ＃１およびローカルメモリ１への電力供給が開始されている。ローカルメモリ１に格納されていたデータは電源停止時に一旦すべて消失している。そこで、ＲＡＩＤコントローラ８０１は、ローカルメモリ１が復帰状態になると、共有メモリ１０４に待避されていたデータを順次、ローカルメモリ内に復元する。
　具体的には、図２８のようにＲＡＩＤコントローラ８０１は、まず、データ待避部９０６によって、共有メモリ１０４からＤＡＴＡ２１を読み込み、ローカルメモリ１内に復帰する。その後、パリティデータ生成部９０２は、現在各ローカルメモリに格納されているデータを復元するための、パリティデータを生成する。
　図２８の例では、パリティ生成部９０２は、ローカルメモリ０に格納されているＤＡＴＡ１１と、ローカルメモリ１に格納されているＤＡＴＡ２１とローカルメモリ２に格納されているＤＡＴＡ３１を利用してＰａｒｉｔｙ１１，２１，３１を生成する。生成されたパリティデータ（Ｐａｒｉｔｙ１１，２１，３１）は、パリティ再構築部９０３によって、現在ローカルメモリ３の中のパリティデータ（Ｐａｒｉｔｙ１１，３１）が格納されている位置に上書きされる。
　ＲＡＩＤコントローラ８０１は、ＤＡＴＡ１１以降のデータについても同様に共有メモリ１０４から読み出してローカルメモリ１に格納する。その後、未再構成のデータを処理する場合がある。ここで未再構成とは、電源停止後に、パリティデータによって共有メモリ１０４に復元データが生成されていないデータを意味する。本来、停止されたローカルメモリに格納されていたデータは、パリティデータによって共有メモリ１０４に再構成される。ところが、電源停止から復帰までの期間が短い場合にはすべてのデータが共有メモリ１０４に再構成される前の状態で復帰処理が始まってしまうこともある。
　図２９では、ＤＡＴＡ２４が共有メモリ１０４内に再構成されていない場合を表している。このような再構成されていないデータの場合、単純に共有メモリ１０４から読み込んでローカルメモリ１に復帰させることはできない。そこで、復元データ生成部９０５によって、パリティデータからＤＡＴＡ２４が生成される。
　ＤＡＴＡ２４は、具体的には、ローカルメモリ０に格納されたＤＡＴＡ１４と、ローカルメモリ２に格納されたＤＡＴＡ３４と、ローカルメモリ３に格納されたＰａｒｉｔｙ１４，２４，３４との排他的論理和演算を行うことによって得られる。図２８のように、ＣＰＵの電源が停止された後に再構築されたパリティデータは、図２８のローカルメモリ３に格納されていたＰａｒｉｔｙ１１，３１と自ローカルメモリ以外の２つのＤＡＴＡに基づいて対象となるデータが復元されている。
　したがって、Ｐａｒｉｔｙ１４，２４，３４など、３つのローカルメモリに格納されているデータによって復元されるようなパリティデータが格納されていることは、すなわち、ＤＡＴＡ２４以降のデータのように、停止後のパリティデータの再構築の済んでいないデータがあることを意味している。
　上述の図２５～２９にて説明したように、電源停止時にはＯＳからＲＡＩＤコントローラ８０１へ電力供給の再開に関する指示が入力される。ＲＡＩＤコントローラ８０１は、コマンド受信部９０４によってＯＳからの指示に応答してデータの復元やパリティデータの再構築を行う。ＲＡＩＤコントローラ８０１は、電源停止中に他のＣＰＵから停止中のローカルメモリへのアクセスが発生し、データの内容が更新されるような場合であっても、共有メモリ１０４に復元したデータに対して書込処理を施すように誘導している（詳しくは上記＜停止中のアクセス＞参照）。したがって、共有メモリ１０４に待避されているデータをローカルメモリに復帰させるだけで、ローカルメモリは、即座に最新の更新内容が反映されたデータが格納されたことになる。
＜電源復帰中のアクセス＞
　図３０は、復元中のローカルメモリへのアクセス例を示す説明図である。マルチコアプロセッサ８００によって実行する処理の内容やタイミングによっては、図３０のように復帰中のローカルメモリに対するアクセスが発生することがある。復帰処理によって既にローカルメモリ内に復帰したデータに対するアクセスの場合には問題がない。
　ところが、図３０のように、ローカルメモリ内に復帰していないデータに対するアクセスの場合には、対象となるデータは存在しない。そこで、ＲＡＩＤコントローラ８０１は、ＣＰＵ＃０からのアクセスを検出して、ＣＰＵ＃０の要求をローカルメモリ１の代わりに受け持って、実際に対象となるデータを復元してアクセス可能にする。
　図３１は、復元中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。図３１のフローチャートは、復元中のローカルメモリへのアクセスが発生した際のアクセス内容に応じたＲＡＩＤコントローラ８０１の動作の違いを表している。
　図３１において、メモリアクセス監視部９０１は、復元中のローカルメモリへのアクセスの検出をトリガにして処理を開始する。メモリアクセス監視部９０１は、まず、検出したアクセスが読込処理か否かを判断する（ステップＳ３１０１）。ステップＳ３１０１において、検出したアクセスが読込処理であると判断された場合（ステップＳ３１０１：Ｙｅｓ）、メモリアクセス監視部９０１は、アクセス先のデータが再構成済みか否かを判断する（ステップＳ３１０２）。
　ステップＳ３１０２において、再構成済みのデータでないと判断された場合（ステップＳ３１０２：Ｎｏ）、メモリアクセス監視部９０１は、現状ではアクセス対象となるデータが存在しないため、パリティデータからローカルメモリに格納されていたデータを復元する（ステップＳ３１０３）。一方、ステップＳ３１０２において、再構成済みのデータであると判断された場合（ステップＳ３１０２：Ｙｅｓ）、対象となるデータは共有メモリ１０４に復元済みであることを意味する。したがって、メモリアクセス監視部９０１は、共有メモリ１０４に待避したデータを読み込む（ステップＳ３１０４）。
　ステップＳ３１０１によってアクセスが読込処理と判断された場合には、ステップＳ３１０３もしくはＳ３１０４の処理によって対象となるデータが読み込まれる。したがって、メモリアクセス監視部９０１は、読込元ＣＰＵにデータを返して（ステップＳ３１０５）、一連の処理を終了する。
　なお、ステップＳ３１０１において、読込処理ではないと判断された場合（ステップＳ３１０１：Ｎｏ）、メモリアクセス監視部９０１は、今回検出したアクセスは書込処理であると判断する。したがって、メモリアクセス監視部９０１は、対象となるローカルメモリへ書き込んで（ステップＳ３１０６）、一連の処理を終了する。その後、ステップＳ３１０６によって書き込まれたデータが最新のデータとなるため、メモリアクセス監視部９０１は、最新のデータを復元するためのパリティデータを生成して現在のパリティデータに対して更新を行う（ステップＳ３１０７）。
　ステップＳ３１０７によってパリティデータの更新の指示がなされると、パリティ生成部９０２では、上述したように最新のデータを復元するためのパリティデータを生成する。パリティ生成部９０２は、まず、対象となるデータの読込を行う（ステップＳ３１２１）。
　続いてパリティ生成部９０２は、ステップＳ３１２１において読み込まれたデータを用いてパリティデータを生成する（ステップＳ３１２２）。最後に、パリティ生成部９０２は、対応するパリティデータを、ステップＳ３１２２にて生成されたパリティデータに更新して（ステップＳ３１２３）、一連の処理を終了する。
　また、上述したように、今回検出されたアクセスが読込処理であり、対象となるデータが再構成されていなかった場合には、ステップＳ３１０３によってデータが復元されている。ステップＳ３１０３において、データを復元する際の処理の主体は復元データ生成部９０５となる。
　具体的に説明すると、復元データ生成部９０５は、ステップＳ３１０３の処理がトリガとなり、一連の処理を開始する。復元データ生成部９０５は、まず、対応するデータ（パリティデータ）を読み込み（ステップＳ３１１１）、読み込んだデータを利用して、ローカルメモリに格納されていたデータを復元データとして生成する（ステップＳ３１１２）。
　ステップＳ３１１２によって生成されたデータは、メモリアクセス監視部９０１に返され、ステップＳ３１０５の処理に利用される。以下に、復元中のローカルメモリへの読込処理と書込処理との手順について具体例を挙げて説明する。
　図３２～３４は、復元中のＣＰＵ＃１への読込動作の手順を示す説明図である。図３２では、ＣＰＵ＃０からＣＰＵ＃１がアクセスするローカルメモリ１に格納されている各データに対する読込動作が発生している。図３２のように、ローカルメモリ１には、ＤＡＴＡ２１，２２のデータが復元済みである。したがって、ＣＰＵ＃０は、ＤＡＴＡ２１を読み込む際には、ローカルメモリ１を参照する。このときＲＡＩＤコントローラ８０１のメモリアクセス監視部９０１は、ＣＰＵ＃０による読込動作の発生を検出する。
　図３３に示すように、ＣＰＵ＃０が、ＤＡＴＡ２３を読み込む場合、メモリアクセス監視部９０１は、ＣＰＵ＃０に通知して、データ待避部９０６によって、共有メモリ１０４に復帰されたＤＡＴＡ２３を読み込ませる。
　さらに、図３４に示すように、ローカルメモリ１にも共有メモリ１０４にも復元されていないＤＡＴＡ２４を読み込む場合、ＲＡＩＤコントローラ８０１は、まず、メモリアクセス監視部９０１によって、復元中のデータへのアクセスであることを検出する。
　復元データ生成部９０５では、ローカルメモリ１以外の稼働中のローカルメモリ（ローカルメモリ０，２，３）に格納されているＤＡＴＡ１３，ＤＡＴＡ３３およびＰａｒｉｔｙ１４，２４，３４によってＤＡＴＡ２４を復元する。復元されたデータは、ローカルメモリ１に格納され、ＣＰＵ＃０によって読み込まれる。
　図３５，３６は、復元中のＣＰＵ＃１への書込動作の手順を示す説明図である。図３５では、ＣＰＵ＃０からＣＰＵ＃１がアクセスするローカルメモリ１に格納されている各データに対する書込動作が発生している。図３５のように、ローカルメモリ１には、ＤＡＴＡ２１，２２のデータが復元済みである。したがって、ＣＰＵ＃０は、ＤＡＴＡ２１への書込を行う際には、ローカルメモリ１にそのままアクセスする。このときＲＡＩＤコントローラ８０１のメモリアクセス監視部９０１は、ＣＰＵ＃０による書込動作の発生を検出する。
　また、図３５のように、ＤＡＴＡ２１の内容が更新されると、パリティ生成部９０２は、更新後のデータを復元できるように、新たなパリティデータを生成し、現在のパリティデータに上書きする。
　その後、図３６のように、ローカルメモリ１内に復元されていないＤＡＴＡ２４への書込処理が発生した場合には、ＣＰＵ＃０は、そのままローカルメモリ１への書込処理を行う。読込処理と異なり、書込処理の場合には、データの内容が上書きされるため、ＤＡＴＡ２４を復元する必要がない。なお、新たにＤＡＴＡ２４が書き込まれた場合、パリティ生成部９０２は、更新後のデータを復元できるように、新たなパリティデータを生成し、現在のパリティデータに上書きする。
　以上説明したように、復元中のローカルメモリへのアクセスが発生した場合には、読込処理であるのか書込処理であるのかに応じてＲＡＩＤコントローラ８０１の処理内容が異なる。読込処理であった場合には、さらに、読込処理の対象となるデータが再構成済みのデータであれば単純に共有メモリ１０４から読み込むように誘導すればよいが、再構成済みのデータではない場合には、逐一復元データを生成して、アクセス元のＣＰＵに読み込ませる必要がある。
　しかしながら、読込処理が完了した後は、データ自体に変更はないためそのまま一連の処理を終わらせることができる。また、書込処理によってデータ自体の変更があった場合には、書込処理を反映させた最新のパリティデータを生成して稼働中のＣＰＵのローカルメモリへ格納することによって、また、急にＣＰＵの電源停止が起こっても、高速に最新のデータを復元することができる。
　以上説明したように、実施例１では、ＣＰＵへの電源停止に伴ってローカルメモリへの電力供給が停止して消費電力を削減する構成になっている。通常、揮発性メモリであるローカルメモリへの電力の供給が停止すると、格納されていたデータは消失してしまい、復元することはできない。ところが、実施例１のデータ復元装置１１０は、あらかじめ、各ローカルメモリに格納されているデータを復元するためのパリティデータを、稼働中のローカルメモリにそれぞれ格納する。したがって、もしＣＰＵ１が電源停止となり、ローカルメモリ１への電力の供給が急に途絶えたとしても、ローカルメモリ１に格納されているデータ自体は消失してしまうが、即座に格納されていたデータを復元することができる。
　また、マルチコアプロセッサ８００では、不必要なＣＰＵを停止させて、電力効率を上げるために、各ＣＰＵに対する電源停止や電源復帰が頻繁に発生するような利用形態が想定される。したがって、パリティデータによるデータの復元やパリティデータの再構築が完全に完了する前にもかかわらず、データの復元が不完全な状態のローカルメモリへアクセスが発生することもある。
　そこで、実施例１では、ＲＡＩＤコントローラ８０１によって、対象となるデータが現在どのような状態であるかを管理している。したがって、ＣＰＵによるアクセスエラーやデータの更新漏れのない、適切かつ効率的なアクセスを支援することができる。
（実施例２）
　図３７は、アクセス監視バスを備えたマルチコアプロセッサの構成例を示す説明図である。実施例２および後述する実施例３は、実施例１とは異なり、ローカルメモリバス１０２の備わっていないマルチコアプロセッサ３７００を利用する場合について説明する。マルチコアプロセッサによっては設計や構造の制約上、実施例１のようなローカルメモリバス１０２を備えていないものもある。実施例２，３では、上述のようにローカルメモリなバス１０２が備えられていないマルチコアプロセッサを対象としたデータ復元処理の実施例について説明する。
　ローカルメモリバス１０２が備わっていないとは、ローカルメモリ同士が相互にアクセスできないということを意味する。すなわち、各ＣＰＵは、自ＣＰＵ以外の他のＣＰＵがどのようなアクセスを行っているかを把握することができない。
　そこで、実施例２のマルチコアプロセッサ３７００の場合、新たにアクセス監視バス３７０１を追加した構成にすることによって、ＲＡＩＤコントローラ３８００による各ローカルメモリへのアクセスの監視や、パリティデータの更新およびローカルメモリ電源停止時のデータ待避を可能にする。
　図３８は、実施例２におけるＲＡＩＤコントローラの内部構成を示すブロック図である。図３８のように、ＲＡＩＤコントローラ３８００は、実施例１と同様に、ローカルメモリの更新を監視するメモリアクセス監視部９０１と、パリティデータを生成するパリティ生成部９０２と、パリティデータの再構築を行うパリティ再構築部９０３と、ＣＰＵからの電源停止のコマンドを受信するコマンド受信部９０４と、パリティデータからローカルメモリに格納されていたデータを復元する復元データ生成部９０５と、電源停止時にローカルメモリの内容を待避するデータ待避部９０６と、を備えている。
　加えて、実施例２のＲＡＩＤコントローラ３８００は、電源再開時にローカルメモリの内容を復元するデータ復帰部９０７と、ローカルメモリの稼働状態を記録するローカルメモリ稼働情報テーブル３８０１とを備えている。ローカルメモリ稼働情報テーブル３８０１は、ＣＰＵ＃０～３の稼働状況を管理するデータテーブルである。したがって、対応するＣＰＵの稼働状況に応じて、「稼働」もしくは「停止」のいずれかの情報が設定されている。
＜電源停止時の動作＞
　図３９は、実施例２における電源停止時のＯＳの動作手順を示すフローチャートである。図３９のフローチャートは、マルチコアプロセッサ３７００内のいずれかのＣＰＵの電源停止時にＯＳからＲＡＩＤコントローラ３８００へ出力される指示内容と、その手順を表している。
　図３９において、ＯＳは電源停止の決定をトリガに動作を開始する。まず、ＯＳは、現在のＣＰＵ数が規定値以下か否かを判断する（ステップＳ３９０１）。ステップＳ３９０１において、ＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ３９０１：Ｎｏ）、ＯＳは、パリティが再構成中か否かを判断する（ステップＳ３９０２）。
　ステップＳ３９０２において、パリティが再構成中であると判断された場合（ステップＳ３９０２：Ｙｅｓ）、ＯＳは、再構成が完了するまで待ち（ステップＳ３９０３）、レジスタの内容を共有メモリ１０４に待避させる（ステップＳ３９０４）。なお、ステップＳ３９０２において、パリティが再構成中ではないと判断された場合（ステップＳ３９０２：Ｎｏ）、ステップＳ３９０３によって待機することなく、ステップＳ３９０４の処理に移行する。
　その後、ＯＳは、キャッシュをフラッシュして（ステップＳ３９０５）、ＲＡＩＤコントローラ３８００に対象となるＣＰＵの停止を通知する（ステップＳ３９０６）。さらに、ＯＳは、他のプロセッサに対象となるＣＰＵの停止を通知し（ステップＳ３９０７）、電源機構を操作して（ステップＳ３９０８）、対象となるＣＰＵへの電力供給を完全に停止させ、一連の処理を終了する。
　一方、ステップＳ３９０１において、ＣＰＵ数が規定値以下と判断された場合（ステップＳ３９０１：Ｙｅｓ）、ＯＳは、レジスタの内容をメモリに待避し（ステップＳ３９０９）、ローカルメモリの内容をメモリに待避する（ステップＳ３９１０）。その後、ＯＳは、キャッシュをフラッシュし（ステップＳ３９１１）、ステップＳ３９０７の処理に移行する。
　以上説明したように、マルチコアプロセッサ３７００のＣＰＵを停止させて、稼働中のローカルメモリのいずれかへの電力の供給を停止する場合は、まず、ＯＳなどの上位プログラムによって、従来通りレジスタの待避とキャッシュのフラッシュを行う。その後、ＯＳは、ローカルメモリの内容は待避せずにＲＡＩＤコントローラ３８００に自ＣＰＵの停止を通知してから電源を切る。
　なお、電源を切る際に、直前に別のＣＰＵの電源が停止されており、パリティデータが再構築中の場合は、ＲＡＩＤコントローラ３８００に現在の状態を問い合わせる。そして、再構築が終了するまで待ってから自ＣＰＵの電源を切る。また、実施例１でも説明したが、停止するＣＰＵ数が増えるとローカルメモリ一つあたりのパリティデータに必要な領域が（データ領域サイズ／稼働数）と増えてしまう。
　したがって、あらかじめ用意されたパリティデータ領域に収まらなくなった場合に備えて、現在の稼働ローカルメモリ数が規定値以下の場合は、ＲＡＩＤコントローラ３８００は利用せず、従来通り、ローカルメモリに格納されているデータを共有メモリ１０４に待避してから電源を停止する処理を採用する。以下には、上述した電源停止時に各機能部の処理内容について、それぞれ説明する。
　図４０は、コマンド受信部の動作手順を示すフローチャートである。図４０のフローチャートは、電源停止時にコマンド受信部９０４によって実行される処理内容を表している。図４０に示しているように、電源停止はＯＳからＣＰＵへの電源停止コマンドによってその処理が実行される。したがって、ＲＡＩＤコントローラ３８００では、コマンド受信部９０４によるコマンド受信によって一連の動作が開始される。
　図４０において、コマンド受信部９０４は、なんらかのコマンド受信をトリガに動作を開始する。まず、コマンド受信部９０４は、受信コマンドを解析する（ステップＳ４００１）。ステップＳ４００１の解析の結果、コマンドが電源停止の指示だった場合（ステップＳ４００１：電源停止）、コマンド受信部９０４は、ローカルメモリ稼働情報テーブル３８０１を待避中に更新する（ステップＳ４００２）。さらに、コマンド受信部９０４は、データ待避部９０６に対して、停止したローカルメモリを通知して（ステップＳ４００３）、一連の処理を終了する。
　一方、ステップＳ４００１の解析の結果、コマンドが電源復帰の指示だった場合（ステップＳ４００１：電源復帰）、コマンド受信部９０４は、ローカルメモリ稼働情報テーブル３８０１を停止中に更新する（ステップＳ４００４）。さらに、コマンド受信部９０４は、データ復帰部９０７に対して復帰したローカルメモリを通知して（ステップＳ４００５）、一連の処理を終了する。
　図４１は、実施例２におけるデータ待避部の動作手順を示すフローチャートである。図４１のフローチャートは、電源停止時にデータ待避部９０６によって実行される処理内容を表している。
　図４１において、データ待避部９０６は、まず、アドレスを０に設定すると（ステップＳ４１０１）、復元データ生成部９０５に復元対象のローカルメモリとアドレスを指示する（ステップＳ４１０２）。さらに、データ待避部９０６は、復元データ生成部９０５から受け取ったデータを共有メモリ１０４に待避する（ステップＳ４１０３）。
　その後、データ待避部９０６は、停止後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４１０４）。ステップＳ４１０４において、ＣＰＵ数が規定値以上と判断された場合（ステップＳ４１０４：Ｙｅｓ）、データ待避部９０６は、復元に使ったパリティデータの場所をパリティ再構築部９０３に通知する（ステップＳ４１０５）。
　その後、データ待避部９０６は、アドレスをインクリメントし（ステップＳ４１０６）、データ領域の待避が完了したか否かを判断する（ステップＳ４１０７）。なお、ステップＳ４１０４において、ＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ４１０４：Ｎｏ）、データ待避部９０６は、ステップＳ４１０５の処理を行わずに、ステップＳ４１０６の処理に移行してアドレスをインクリメントする。
　その後、データ待避部９０６は、ステップＳ４１０７において、データ領域の待避が完了するまでステップＳ４１０２の処理に戻り、インクリメント後のアドレスを対象とした処理を繰り返す（ステップＳ４１０７：Ｎｏのループ）。
　ステップＳ４１０７において、データ領域の待避が完了したと判断された場合（ステップＳ４１０７：Ｙｅｓ）、データ待避部９０６は、停止後のＣＰＵ数が規定値以下か否かを判断する（ステップＳ４１０８）。ステップＳ４１０８において、ＣＰＵ数が規定値以下であると判断された場合（ステップＳ４１０８：Ｙｅｓ）、データ待避部９０６は、パリティ再構築部９０３に待避完了を通知して（ステップＳ４１０９）、一連の処理を終了する。
　なお、ステップＳ４１０８において、停止後のＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ４１０８：Ｎｏ）、データ待避部９０６は、ステップＳ４１０９の処理を行わずに、そのまま一連の処理を終了する。
　図４２は、実施例２における復元データ生成部の動作手順を示すフローチャートである。図４２のフローチャートは、電源停止時に復元データ生成部９０５によって実行される処理内容を表している。
　図４２において、復元データ生成部９０５は、まず、指示された復元対象に対応するデータを読み込む（ステップＳ４２０１）。その後、復元データ生成部９０５は、復元データを生成し（ステップＳ４２０２）、一連の処理を終了する。
　図４３は、パリティ再構築部の動作手順を示すフローチャートである。図４３のフローチャートは、パリティ再構築部９０３による通知内容に応じたパリティデータに関する処理を表している。図４３の各処理を実行することによって、パリティ再構築部９０３は、適切なパリティデータを生成すると共に、生成したパリティデータを適切な箇所に格納することができる。
　図４３において、パリティ再構築部９０３は、他の機能部からの、なんらかの通知の受信をトリガに動作を開始する。まず、パリティ再構築部９０３が受信する通知としては、パリティデータの生成の通知、待避完了の通知、復元完了の通知の３種類がある。したがって、いずれの通知を受信したかに応じてパリティ再構築部９０３の動作内容も変化する。
　まず、パリティデータの生成が通知された場合、パリティ再構築部９０３は、パリティ生成部９０２に通知されたパリティの場所を指示する（ステップＳ４３０１）。その後、パリティ再構築部９０３は、生成されたパリティデータを書き込み（ステップＳ４３０２）、一連の処理を終了する。
　次に、待避完了が通知された場合、パリティ再構築部９０３は、停止前後の稼働中のローカルメモリ数から未再構成の領域を算出する（ステップＳ４３０３）。さらに、パリティ再構築部９０３は、パリティ生成部９０２にパリティの場所を指示すると（ステップＳ４３０４）、生成されたパリティデータを書き込む（ステップＳ４３０５）。
　その後、パリティ再構築部９０３は、未再構成のデータがあるか否かを判断する（ステップＳ４３０６）。ステップＳ４３０６において、未再構成のデータがあると判断された場合（ステップＳ４３０６：Ｙｅｓ）、パリティ再構築部９０３は、ステップＳ４３０４の処理に戻り、未再構成のデータに対する処理を継続する。
　一方、ステップＳ４３０６において、未再構成のデータがないと判断されると（ステップＳ４３０６：Ｎｏ）、パリティ再構築部９０３は、ローカルメモリ稼働委情報テーブル３８０１を停止に更新して（ステップＳ４３０７）、一連の処理を終了する。
　また、復元完了が通知された場合、パリティ再構築部９０３は、稼働ローカルメモリ数から復帰したローカルメモリの未再構成領域を算出する（ステップＳ４３０８）。その後、パリティ再構築部９０３は、パリティ生成部９０２にパリティの場所を指示し（ステップＳ４３０９）、生成されたパリティデータを書き込む（ステップＳ４３１０）。
　そして、パリティ再構築部９０３は、未再構成のデータがあるか否かを判断する（ステップＳ４３１１）。ステップＳ４３１１において、未再構成のデータがあると判断された場合（ステップＳ４３１１：Ｙｅｓ）、パリティ再構築部９０３は、ステップＳ４３０９の処理に戻り、未再構成のデータに対する処理を継続する。
　一方、ステップＳ４３１１において、未再構成のデータがないと判断されると（ステップＳ４３１１：Ｎｏ）、パリティ再構築部９０３は、ローカルメモリ稼働情報テーブル３８０１を稼働中に更新して（ステップＳ４３１２）、一連の処理を終了する。
　図４４は、パリティ生成部の動作手順を示すフローチャートである。図４３のフローチャートは、パリティ生成部９０２によって実行される処理内容を表している。
　図４４において、パリティ生成部９０２は、まず、指示されたパリティに対応するデータを読み込む（ステップＳ４４０１）。その後、パリティ生成部９０２は、パリティデータを生成し（ステップＳ４４０２）、一連の処理を終了する。
　以上、図４０～４４にて説明したように、コマンド受信部９０４は、ＲＡＩＤコントローラ３８００では、電源停止が通知されると、まずコマンド受信部９０４が受信したコマンドの情報に応じてローカルメモリ稼働情報テーブル３８０１を更新する。また、データ待避部９０６に停止したローカルメモリの内容の待避を指示する。また、停止後の稼働ローカルメモリ数が規定値以上の場合はパリティ再構築部９０３にも指示を出し、平行してパリティデータの再構築を行う。
　また、パリティ再構築部９０３では、データ復帰部９０７によって待避領域から復帰したデータに対応するパリティデータを再構築する。そして、待避領域から復帰したデータの再構築が終了すると、復帰したローカルメモリのパリティ領域に対応するパリティデータを再構築する。
　そして、データ待避部９０６およびパリティ再構築部９０３では、データ待避部９０６が停止されたローカルメモリのデータ領域の先頭から待避を行う。このとき、データ復帰部９０７を利用して、データを復元した後、あらかじめ定められた待避領域へ待避していく。データ復帰部９０７では、データ待避部９０６から指示されたデータを復元するためのパリティデータとこれに対応するデータを稼働中のローカルメモリから読み込んで停止したローカルメモリのデータを復帰する。
　また、パリティ再構築部９０３ではここで待避が完了したパリティデータ領域にパリティ生成部９０２を利用して順次パリティデータを再構築していく。停止したローカルメモリの全データ領域の待避が完了したら、残りの領域に対しても順次パリティデータを生成していく。
＜電源復帰時の動作＞
　図４５は、実施例２における電源復帰時のＯＳの動作手順を示すフローチャートである。図４５のフローチャートは、実施例２において、マルチコアプロセッサ３７００のなかの停止中のＣＰＵの電源を復帰させる際のＯＳの処理内容を示している。
　図４５において、ＯＳは、電源停止からの復帰をトリガに処理を開始する。まず、ＯＳは、他のプロセッサのローカルメモリを待避中か否かを判断する（ステップＳ４５０１）。ステップＳ４５０１において、他のプロセッサのローカルメモリを待避中であると判断された場合（ステップＳ４５０１：Ｙｅｓ）、ＯＳは、待避が完了するまで待機状態となる（ステップＳ４５０２）。
　ＯＳは、他のプロセッサのローカルメモリが待避中ではない（ステップＳ４５０１：Ｎｏ）、もしくは、待避が完了するまで待つと（ステップＳ４５０２）、ＲＡＩＤコントローラ３８００に復帰を通知する（ステップＳ４５０３）。その後、ＯＳは、プロセッサのレジスタの内容を復元する（ステップＳ４５０４）。
　さらに、ＯＳは、ＲＡＩＤコントローラ３８００によりローカルメモリが復元されるまで待ち（ステップＳ４５０５）、他のプロセッサに復帰を通知する（ステップＳ４５０６）。その後、ＯＳは、通常の処理を再開させて（ステップＳ４５０７）、一連の復帰処理を終了する。
　以上説明したように、実施例２では、ＣＰＵへの電力供給を再開する場合は、電力供給が再開されたＣＰＵによって実行されているＯＳよりレジスタの内容を復元する。また、ＯＳは、同時にＲＡＩＤコントローラ３８００に自身の復帰を通知するため、ＲＡＩＤコントローラ３８００による復元の完了を待って停止前の処理を再開することができる。
　図４６は、データ復帰部の動作手順を示すフローチャートである。図４６は、電源復帰時におけるデータ復帰部９０７にて実行される処理内容を表している。
　図４６において、データ復帰部９０７は、まず、ローカルメモリ稼働情報テーブル３８０１を確認し（ステップＳ４６０１）、待避中か否かを判断する（ステップＳ４６０２）。ステップＳ４６０２において、ローカルメモリ稼働情報テーブル３８０１が待避中と判断された場合（ステップＳ４６０２：Ｙｅｓ）、データ復帰部９０７は、データ待避部９０６に待避中止を通知する（ステップＳ４６０３）。
　その後、データ復帰部９０７は、データ待避部９０６から最後に待避したアドレスを取得し（ステップＳ４６０４）、その後、アドレスを０に、終了アドレスをステップＳ４６０４によって取得したアドレスに設定する（ステップＳ４６０５）。
　一方、ステップＳ４６０２において、待避中でないと判断された場合（ステップＳ４６０２：Ｎｏ）、データ復帰部９０７は、アドレスを０、終了アドレスをデータ領域の最終アドレスに設定する（ステップＳ４６０６）。
　ステップＳ４６０５もしくはステップＳ４６０６において、アドレス設定が行われると、データ復帰部９０７は、待避したデータをローカルメモリに復帰させる（ステップＳ４６０７）。そして、データ復帰部９０７は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４６０８）。
　ステップＳ４６０８において、復元後のＣＰＵ数が規定値以上と判断された場合（ステップＳ４６０８：Ｙｅｓ）、データ復帰部９０７は、復帰したデータに対応するパリティデータをパリティ再構築部９０３に通知する（ステップＳ４６０９）。その後、データ復帰部９０７は、アドレスをインクリメントする（ステップＳ４６１０）。
　一方、ステップＳ４６０８において、復元後のＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ４６０８：Ｎｏ）、データ復帰部９０７は、ステップＳ４６０９の処理を行わずに、ステップＳ４６１１の処理に移行する。
　次に、データ復帰部９０７は、終了アドレスに到達したか否かを判断する（ステップＳ４６１１）。ステップＳ４６１１において、終了アドレスに到達していない場合（ステップＳ４６１１：Ｎｏ）、データ復帰部９０７は、ステップＳ４６０７に戻り、インクリメント後のアドレスを対象に処理を行う。
　その後、ステップＳ４６１１において、終了アドレスに到達したと判断された場合（ステップＳ４６１１：Ｙｅｓ）、データ復帰部９０７は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４６１２）。ステップＳ４６１２において、ＣＰＵ数が規定値以上であると判断された場合（ステップＳ４６１２：Ｙｅｓ）、データ復帰部９０７は、パリティ再構築部９０３に復元終了を通知して（ステップＳ４６１３）、一連の処理を終了する。一方、ステップＳ４６１２において、ＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ４６１２：Ｎｏ）、データ復帰部９０７は、ステップＳ４６１３の処理を行わずに、一連の処理を終了する。
　以上説明したように、実施例２のデータ復帰部９０７は、ローカルメモリ稼働情報テーブル３８０１を参照して復帰したローカルメモリが直前に停止されたものでなければ全データは待避済みと判断する。したがって、データ復帰部９０７は、待避されたデータからローカルメモリに復元する。また、直前に停止されたＣＰＵの場合は、データ待避部９０６は、ローカルメモリ稼働情報テーブル３８０１を参照する。そして、未待避のデータがある場合は復元データ生成部９０５によって、未処理の再構築前のパリティデータからローカルメモリへデータを復元することによって、漏れなくデータを復帰することができる。
（実施例３）
　実施例３では、実施例２と、同じく図５１に示したマルチコアプロセッサ３７００の構成を利用する。しかしながら、実施例２と異なり、ＲＡＩＤコントローラ３８００にローカルメモリの待避復帰状況を記録する待避復帰情報４８０１（図４８参照）を追加する。待避復帰情報４８０１にローカルメモリの待避復帰状況を記録してメモリアクセス監視部９０１に読込処理と書込処理の双方を監視させることによって、電源復帰時のローカルメモリへのデータ復元の高速化が期待できる。
＜電源停止時の動作＞
　図４７は、実施例３における電源復帰時のＯＳの動作手順を示すフローチャートである。図４７のフローチャートは、マルチコアプロセッサ３７００内のいずれかのＣＰＵの電源停止時にＯＳからＲＡＩＤコントローラ４８００（図３７参照）へ出力される指示内容と、その手順を表している。
　図４７において、マルチコアプロセッサのＯＳは、電源停止からの復帰指示をトリガに動作を開始する。まず、ＯＳは、ＲＡＩＤコントローラ４８００に復帰を通知する（ステップＳ４７０１）。つぎに、ＯＳは、復帰したプロセッサ（たとえばＣＰＵ＃１）のレジスタの内容を復元すると（ステップＳ４７０２）、他のプロセッサに復帰を通知する（ステップＳ４７０３）。その後、ＯＳは、復帰したプロセッサの通常の処理を再開させ（ステップＳ４７０４）、電源復帰時の一連の動作を終了する。以上説明したように、実施例３の場合、電源復帰時のＯＳは、ＲＡＩＤコントローラ４８００によるローカルメモリの内容の復帰を待たずに処理を開始する。
　図４８は、実施例３におけるＲＡＩＤコントローラの内部構成を示すブロック図である。図４８に示したように、実施例３の場合、ＲＡＩＤコントローラ４８００は、実施例２のＲＡＩＤコントローラ３８００に待避復帰情報４８０１が追加された構成になっている。
　また、ＲＡＩＤコントローラ４８００の場合、メモリアクセス監視部９０１では、実施例２にて説明した監視処理に加えて、復帰中のローカルメモリへのアクセスを監視することができる。復帰中のローカルメモリへのアクセスを監視することによって、ＲＡＩＤコントローラ４８００は、復帰前のローカルメモリデータへのリードがあった場合には、ＲＡＩＤコントローラ４８００が対象のデータを先に復帰して値を返すことができる。そして、ＲＡＩＤコントローラ４８００は、ライトがあった場合には、通常通りパリティデータを更新して、対象となるデータを復帰しないように待避復帰情報を更新することができる。
　図４９は、メモリアクセス監視部の動作手順を示すフローチャートである。図４９のフローチャートは、メモリアクセス監視部９０１によって実行される処理内容を表している。
　図４９において、メモリアクセス監視部９０１は、いずれかのローカルメモリへのアクセスの検出をトリガに動作を開始する。そして、メモリアクセス監視部９０１は、まず、ローカルメモリ稼働情報テーブル３８０１の対象エントリを確認する（ステップＳ４９０１）。次に、メモリアクセス監視部９０１は、ステップＳ４９０１において確認したエントリが復帰中か否かを判断する（ステップＳ４９０２）。
　ステップＳ４９０２において、確認したエントリが復帰中であると判断された場合（ステップＳ４９０２：Ｙｅｓ）、続いて、メモリアクセス監視部９０１は、確認したエントリがいずれかのローカルメモリへのライトアクセスか否かを判断する（ステップＳ４９０３）。ステップＳ４９０３において、確認したエントリがライトアクセスであると判断された場合（ステップＳ４９０３：Ｙｅｓ）、メモリアクセス監視部９０１は、対応するパリティデータの場所を算出する（ステップＳ４９０４）。
　ステップＳ４９０４によってパリティデータの場所が算出されると、メモリアクセス監視部９０１は、パリティ生成部９０２に算出した場所を通知する（ステップＳ４９０５）。その後、メモリアクセス監視部９０１は、生成されたパリティデータをローカルメモリに書き込み（ステップＳ４９０６）、書き込みデータに対応する待避復帰情報４８０１を復帰に更新して（ステップＳ４９０７）、一連の処理を終了する。
　一方、ステップＳ４９０３において、確認したエントリがライトアクセスではないと判断された場合（ステップＳ４９０３：Ｎｏ）、メモリアクセス監視部９０１は、対応する待避復帰情報４８０１を確認する（ステップＳ４９０８）。そして、メモリアクセス監視部９０１は、待避復帰情報４８０１を確認した結果が、復帰状態か否かを判断する（ステップＳ４９０９）。
　ステップＳ４９０９において、確認した結果が復帰状態であった場合（ステップＳ４９０９：Ｙｅｓ）、メモリアクセス監視部９０１は、一連の処理を終了する。一方、確認した結果が復帰状態ではなかった場合（ステップＳ４９０９：Ｎｏ）、メモリアクセス監視部９０１は、今回のアクセスがリードアクセスであると判断して、以後の処理を行う。
　まず、メモリアクセス監視部９０１は、復元データ生成部９０５にリード先の場所を通知する（ステップＳ４９１０）。その後、メモリアクセス監視部９０１は、復元したデータをアクセス元に返し（ステップＳ４９１１）、復元したデータをローカルメモリに書き込む（ステップＳ４９１２）。したがって、メモリアクセス監視部９０１は、対応する待機復帰情報４８０１を復帰に更新する（ステップＳ４９１３）。
　その後、メモリアクセス監視部９０１は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４９１４）。ステップＳ４９１４において、ＣＰＵ数が規定値以上と判断された場合（ステップＳ４９１４：Ｙｅｓ）、メモリアクセス監視部９０１は、復帰したデータに対応するパリティデータをパリティ再構築部９０３に通知して（ステップＳ４９１５）、一連の処理を終了する。一方、ステップＳ４９１４において、ＣＰＵ数が規定値上ではないと判断された場合（ステップＳ４９１４：Ｎｏ）、メモリアクセス監視部９０１は、そのまま一連の処理を終了する。
　また、ステップＳ４９０２において、確認したエントリが復帰中でないと判断された場合（ステップＳ４９０２：Ｎｏ）、メモリアクセス監視部９０１は、確認したエントリがいずれかのローカルメモリへのライトアクセスか否かを判断する（ステップＳ４９１６）。ステップＳ４９１６において、確認したエントリがライトアクセスであると判断された場合（ステップＳ４９１６：Ｙｅｓ）、メモリアクセス監視部９０１は、対応するパリティデータの場所を算出する（ステップＳ４９１７）。
　ステップＳ４９１７によってパリティデータの場所が算出されると、メモリアクセス監視部９０１は、パリティ生成部９０２に算出した場所を通知する（ステップＳ４９１８）。その後、メモリアクセス監視部９０１は、生成されたパリティデータをローカルメモリに書き込み（ステップＳ４９１９）、一連の処理を終了する。一方、ステップＳ４９１６において、確認したエントリがライトアクセスではないと判断された場合（ステップＳ４９１６：Ｎｏ）、メモリアクセス監視部９０１は、そのまま一連の処理を終了する。
　図５０は、実施例３におけるデータ待避部の動作手順を示すフローチャートである。図５０のフローチャートは、データ待避部９０６によって実行される処理内容を表している。
　図５０において、データ待避部９０６は、まず、アドレスを０に設定し（ステップＳ５００１）、復元データ生成部９０５に復元対象のローカルメモリとアドレスを指示する（ステップＳ５００２）。その後、データ待避部９０６は、復元データ生成部９０５から受け取ったデータを共有メモリ１０４に待避する（ステップＳ５００３）。
　続いて、データ待避部９０６は、停止後のＣＰＵ数が規定値以上か否を判断する（ステップＳ５００４）。ステップＳ５００４において、ＣＰＵ数が規定値以上であると判断された場合（ステップＳ５００４：Ｙｅｓ）、データ待避部９０６は、復元に使ったパリティデータの場所をパリティ再構築部９０３に通知する（ステップＳ５００５）。
　その後、データ待避部９０６は、対応する待避復帰情報４８０１を待避に更新し（ステップＳ５００６）、アドレスをインクリメントする（ステップＳ５００７）。一方、ステップＳ５００４において、ＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ５００４：Ｎｏ）、データ待避部９０６は、ステップＳ５００５～Ｓ５００６の処理を行わずに、そのままステップＳ５００７において、アドレスをインクリメントする。
　ステップＳ５００７の処理の後、データ待避部９０６は、データ領域の待避が完了したか否かを判断し（ステップＳ５００８）、待避が完了していると判断された場合には（ステップＳ５００８：Ｙｅｓ）、さらに、停止後のＣＰＵ数が規定値以下か否かを判断する（ステップＳ５００９）。
　なお、ステップＳ５００８において、データ領域の待避が完了していないと判断された場合（ステップＳ５００８：Ｎｏ）、データ待避部９０６は、ステップＳ５００２の処理に移行して、次のアドレスを対象にした処理を行う。そして、データ待避部９０６は、ステップＳ５００９において、停止後のＣＰＵ数が規定値以下と判断された場合（ステップＳ５００９：Ｙｅｓ）、パリティ再構築部９０３に待避完了を通知して（ステップＳ５０１０）、一連の処理を終了する。
　一方、ステップＳ５００９において、停止後のＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ５００９：Ｎｏ）、データ待避部９０６は、そのまま一連の処理を終了する。
　図５１は、実施例３における復元データ生成部の動作手順を示すフローチャートである。図５１のフローチャートは、実施例３の復元データ生成部９０５によって実行される処理内容を表している。
　図５１において、復元データ生成部９０５は、まず、ローカルメモリ稼働情報テーブル３８０１を確認する（ステップＳ５１０１）。その後、復元データ生成部９０５は、アドレスを０、終了アドレスを、データ領域の最終アドレスに設定する（ステップＳ５１０２）。
　続いて、復元データ生成部９０５は、稼働情報が待避中か否かを判断する（ステップＳ５１０３）。ステップＳ５１０３において、稼働情報が待避中と判断された場合（ステップＳ５１０３：Ｙｅｓ）、復元データ生成部９０５は、対象の待避復帰情報４８０１を確認し（ステップＳ５１０４）、対象データが待避中か否かを判断する（ステップＳ５１０５）。
　ステップＳ５１０５において、対象データが待避中であると判断された場合（ステップＳ５１０５：Ｙｅｓ）、ステップＳ５１０９の処理に移行する。一方、ステップＳ５１０５において、対象データが待避中でないと判断された場合（ステップＳ５１０５：Ｎｏ）、復元データ生成部９０５は、待避したデータをローカルメモリに復帰し（ステップＳ５１０６）、その後、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ５１０７）。
　また、ステップＳ５１０３において、稼働情報が待避中ではないと判断された場合（ステップＳ５１０３：Ｎｏ）にも、復元データ生成部９０５は、ステップＳ５１０６の処理に移行して待避したデータをローカルメモリに復帰する。
　ステップＳ５１０７において、復元後のＣＰＵ数が規定値以上であると判断された場合（ステップＳ５１０７：Ｙｅｓ）、復元データ生成部９０５は、復帰したデータに対応するパリティデータをパリティ再構築部９０３に通知する（ステップＳ５１０８）。なお、ステップＳ５１０７において、復元後のＣＰＵ数が規定値以上でないと判断された場合（ステップＳ５１０７：Ｎｏ）、復元データ生成部９０５は、ステップＳ５１０９の処理に移行する。
　その後、復元データ生成部９０５は、アドレスをインクリメントして（ステップＳ５１０９）、インクリメント後のアドレスが終了アドレスに到達したか否かを判断する（ステップＳ５１１０）。ステップＳ５１１０において、終了アドレスに到達していない場合には（ステップＳ５１１０：Ｎｏ）、復元データ生成部９０５は、ステップＳ５１０３の処理に戻って、次のアドレスに対しての処理を行う。
　その後、ステップＳ５１１０において、終了アドレスに到達したと判断された場合（ステップＳ５１１０：Ｙｅｓ）、復元データ生成部９０５は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ５１１１）。
　そして、ＣＰＵ数が規定値以上と判断された場合（ステップＳ５１１１：Ｙｅｓ）、復元データ生成部９０５は、パリティ再構築部９０３に復元終了を通知して（ステップＳ５１１２）、一連の処理を終了する。なお、ステップＳ５１１１において、ＣＰＵ数が規定値以上でないと判断された場合（ステップＳ５１１１：Ｎｏ）、復元データ生成部９０５は、そのまま一連の処理を終了する。
　以上説明したように、実施例３の場合、メモリアクセス監視部９０１は、また、データ待避部９０６では、データ待避時に待避復帰情報４８０１を更新する。したがって、データ復帰部９０７では、待避復帰情報４８０１を参照して未復帰の情報を復帰すると共に、待避復帰情報を更新することができる。したがって、誤ったデータを待避させるような事態を防ぐと共に、実施例２と比較してより高速な電源停止を実現することができる。
（電力の比較）
　図５２は、データ復元処理を採用した場合の電力比較例を示す説明図である。マルチコアプロセッサの場合、あらかじめ配置されるＣＰＵ数や、同時に稼働させるＣＰＵ数も様々であり、使用状況に応じて電力効率は大きく変わる。しかしながら、従来の技術では、こまめな電源のＯＮ／ＯＦＦは、ローカルメモリに格納されているデータの待避時間を考慮すると待避時間の発生によって十分な省電力効果が得られないことが多かった。
　そこで、図５２を用いて、本実施の形態にかかるデータ復元処理を適用したマルチコアプロセッサと、それ以外のマルチコアプロセッサとの簡単な消費電力の比較結果を例示した。ここではＣＰＵを４つ備えたマルチコアプロセッサについて説明する。
　図５２の上段はローカルメモリの電源を切らない場合の電力を、中断は、従来手法（データを待避するまで電力を供給する）で電力を切る場合の電力を、下段は、本実施の形態にかかるデータ復元処理を利用した場合の電力をそれぞれ表している。また、本実施の形態にかかるデータ復元処理を利用した場合、ＣＰＵが３つ以上稼働中であれば、パリティデータを生成するように設定している。
　また、図５２では、上段以外は、左から右にかけて４つのＣＰＵが稼働している場合、３つのＣＰＵが稼働している場合、２つのＣＰＵが稼働している場合、１つのＣＰＵが稼働している場合の電力変化を表している。
　図５２において、常時４つのＣＰＵが稼働中の上段の手法では常に電力：４（相対値）が消費される。そして、中段の従来手法の場合、稼働中のＣＰＵ数に応じた電力４→３→２→１の電力が消費される。当然のことながら、消費する電力は最小１まで抑えることができる。しかしながら、稼働中のＣＰＵの数の変更に要する処理速度が遅く、マルチコアプロセッサとしての機能の低下が避けられない。
　そして、下段の本実施の形態にかかるデータ復元処理では、パリティデータを作成してパリティの領域に格納するため、稼働しているＣＰＵの数が同じであれば、電源を切らない手法や、従来手法よりも電力の消費が大きくなってしまっている。しかしながら、ＣＰＵの数を変更させる場合であっても、データの待避を行わないため、処理速度が速く、即座に新たなＣＰＵ数に応じた処理に移行することができる。
　したがって、本実施の形態にかかるデータ復元処理は、特にＣＰＵ数が比較的少なく、なおかつ、稼働させるＣＰＵ数が頻繁に変化するようなマルチコアプロセッサへ適用すれば、電力効率の高いシステムの提供が期待できる。
　以上説明したように、本実施の形態にかかるデータ復元プログラム、データ復元装置およびデータ復元方法によれば、揮発性メモリ内に格納されていたデータが消失しても、あらかじめ格納しておいたパリティデータによって揮発性メモリ内に格納されたデータを復元することができる。したがって、ローカルメモリの電源停止時に事前にローカルメモリの内容を待避しておく必要がなくなるため、ローカルメモリの電源停止動作を高速化することができる。
　また、上記技術は、さらに、稼働中の揮発性メモリ数が変化した場合には、格納可能な揮発性メモリの数に応じてパリティデータを作成する。したがって、プロセッサ数が頻繁に変化するような環境であっても、適切な構成のパリティデータを作成することができる。
　また、上記技術では、さらに、一旦電源停止となったプロセッサが始動する場合には、共有メモリに復元されたデータを自動的に揮発性メモリに復帰することもできる。また、プロセッサが始動した際に、共有メモリ内に復元が済んでいないデータに関しては、パリティデータを利用して再構成した後に揮発性メモリに復帰する。したがって、プロセッサの停止や再開が頻繁に起こっても、揮発性メモリに格納され、一旦消失したデータを余すことなく復元することができる。
　また、上記技術では、さらに、稼働中のプロセッサがアクセスする揮発性メモリが停止中である場合には、揮発性メモリに格納されていたデータが再構成されているか否かに応じて、プロセッサのアクセス先を変更することができる。また、揮発性メモリに格納されていたデータが再構成されていなかった場合には、アクセス対象となるデータの再構成を行いプロセッサによるアクセスを支援する。したがって、マルチコアプロセッサの中に停止中のプロセッサが存在しても稼働中の他のプロセッサは他のプロセッサの稼働状態を考慮することなく通常と同じ手順で所望のデータにアクセスすることができる。
　また、上記技術では、さらに、稼働中のプロセッサ数に応じて、揮発性メモリに格納されているデータの待避処理の手法を変更することができる。すなわち、稼働中のプロセッサ数が多く、揮発性メモリにパリティデータを格納しても、各プロセッサの処理速度を低下させない場合には、パリティデータを利用した待避処理を採用して高速な電源停止を実現する。稼働中のプロセッサ数が少なく、パリティデータの格納によって揮発性メモリの容量が圧迫され、プロセッサの処理速度の低下を招いてしまう恐れのある場合には、パリティデータを格納せずに、従来の手法によってデータを待避する。したがって、稼働中のプロセッサ数に応じて最も効率のよい手法を利用するため、マルチコアプロセッサの処理速度を想定値以内に保つことができる。
　なお、本実施の形態で説明したデータ復元方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。本データ復元プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本データ復元プログラムは、インターネットなどのネットワークを介して配布してもよい。
　また、本実施の形態で説明したデータ復元装置１１０は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ　Ｌｏｇｉｃ　Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したデータ復元装置１１０の機能（停止検出部６０１～復帰部６０６）をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、データ復元装置１１０を製造することができる。
　１００，６００　マルチコアプロセッサ
　１０１　電源
　１０２　ローカルメモリバス
　１０３　共有メモリバス
　１０４　共有メモリ
　１１０　データ復元装置
　６０１　停止検出部
　６０２　復元部
　６０３　作成部
　６０４　格納部
　６０５　始動検出部
　６０６　復帰部
　９０１　メモリアクセス監視部
　９０２　パリティ生成部
　９０３　パリティ再構築部
　９０４　コマンド受信部
　９０５　復元データ生成部
　９０６　データ待避部
　９０７　データ復帰部

Claims (13)

  1. 　揮発性メモリおよび当該揮発性メモリにアクセスするプロセッサを複数搭載したマルチコアプロセッサにアクセス可能なコンピュータに、
    　前記マルチコアプロセッサ内の複数のプロセッサの中のいずれかのプロセッサへの停止指示を検出する停止検出工程と、
    　前記停止検出工程によって前記停止指示が検出されると、前記停止指示を受けたプロセッサ以外の稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、前記停止指示を受けたプロセッサがアクセスする揮発性メモリに格納されていたデータを、前記稼働中のプロセッサ群がアクセス可能な共有メモリ内に復元する復元工程と、
    　を実行させることを特徴とするデータ復元プログラム。
  2. 　前記コンピュータに、
    　前記復元工程が実行された後に、前記稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されているデータを復元するパリティデータを作成する作成工程と、
    　前記作成工程によって作成されたパリティデータを、それぞれ前記稼働中のプロセッサ群がアクセスする揮発性メモリのうち、前記パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納する格納工程と、
    　を実行させることを特徴とする請求項１に記載のデータ復元プログラム。
  3. 　前記作成工程は、
    　前記複数のプロセッサの中のいずれかのプロセッサの揮発性メモリに新たにデータが追加または新たなデータに更新されると、前記新たなデータを復元するパリティデータを作成し、
    　前記格納工程は、
    　前記作成工程によって作成されたパリティデータを、それぞれ前記稼働中のプロセッサ群がアクセスする揮発性メモリのうち、前記新たなデータが追加または前記新たなデータに更新された揮発性メモリ以外の揮発性メモリに格納し、
    　前記停止検出工程は、
    　前記新たにデータが追加または前記新たなデータに更新された揮発性メモリへアクセスするプロセッサへの停止指示を検出し、
    　前記復元工程は、
    　前記停止検出工程によって、前記新たにデータが追加または前記新たなデータに更新された揮発性メモリへアクセスするプロセッサへの停止指示が検出されると、前記停止指示を受けたプロセッサ以外の稼働中のプロセッサ群がアクセスする揮発性メモリに格納されたパリティデータに基づいて、前記新たなデータを、前記共有メモリ内に復元することを特徴とする請求項２に記載のデータ復元プログラム。
  4. 　前記作成工程は、
    　前記復元工程が実行された後に、前記稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されている前記新たなデータを復元するパリティデータを作成し、
    　前記格納工程は、
    　前記作成工程によって作成された前記新たなデータを復元するパリティデータを、それぞれ前記稼働中のプロセッサ群がアクセスする揮発性メモリのうち、前記パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納することを特徴とする請求項３に記載のデータ復元プログラム。
  5. 　前記コンピュータに、
    　前記複数のプロセッサの中の停止中のプロセッサへの電力供給の始動を検出する始動検出工程と、
    　前記始動検出工程によって電力供給の始動が検出された場合、前記共有メモリ内に復元されたデータを、前記電力供給の始動が検出されたプロセッサがアクセスする揮発性メモリに格納する復帰工程と、
    　を実行させることを特徴とする請求項１に記載のデータ復元プログラム。
  6. 　前記復帰工程は、
    　前記復元工程による復元中に、前記始動検出工程によって、前記停止中のプロセッサへの電力供給の始動が検出された場合、前記停止指示を受けたプロセッサがアクセスする揮発性メモリに格納されていたデータのうち、前記共有メモリ内に復元されていないデータを、前記稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータを用いて復元して、前記電力供給の始動が検出されたプロセッサがアクセスする揮発性メモリに格納することを特徴とする請求項５に記載のデータ復元プログラム。
  7. 　前記作成工程は、
    　前記データ復帰工程によって前記データが復元された後、前記稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されているデータを復元するパリティデータを作成し、
    　前記格納工程は、
    　前記作成工程によって作成されたパリティデータを、それぞれ前記稼働中のプロセッサ群がアクセスする揮発性メモリのうち、前記パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納することを特徴とする請求項５または６に記載のデータ復元プログラム。
  8. 　前記コンピュータに、
    　前記複数のプロセッサのいずれかのプロセッサがアクセスする揮発性メモリに格納されているデータへの読込要求を検出する読込検出工程と、
    　前記読込検出工程によって読込要求が検出されたデータが格納されている揮発性メモリが稼働中でない場合、前記データが前記共有メモリに格納されていることを前記読込要求に応じて前記データを読み込むプロセッサに通知する通知工程と、
    　を実行させることを特徴とする請求項１に記載のデータ復元プログラム。
  9. 　前記復元工程は、
    　前記データを格納している揮発性メモリが稼働中でなく、かつ、前記データが前記共有メモリ内に復元されていない場合、前記稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、前記データを復元し、
    　前記通知工程は、
    　前記データを格納している揮発性メモリが稼働中でなく、かつ、前記データが前記共有メモリ内に復元されていない場合、前記データが前記復元工程によって復元されたことを前記読込要求に応じて前記データを読み込むプロセッサに通知することを特徴とする請求項８に記載のデータ復元プログラム。
  10. 　前記プロセッサに、
    　前記稼働中のプロセッサの数がしきい値以上か否かを判断する判断工程と、
    　前記複数のプロセッサの中のいずれかのプロセッサへの停止指示を受け付ける受付工程と、
    　前記判断工程によって、前記稼働中のプロセッサの数がしきい値以上と判断された場合、前記受付工程によって前記停止指示が受け付けられたプロセッサおよび当該プロセッサがアクセスする揮発性メモリへの電力供給の停止指示を電源回路に出力する出力工程と、
    　を実行させることを特徴とする請求項１に記載のデータ復元プログラム。
  11. 　前記プロセッサに、
    　前記判断工程によって、前記稼働中のプロセッサの数が前記しきい値以上ではないと判断された場合、前記受付工程によって前記停止指示が受け付けられたプロセッサの揮発性メモリに格納されているデータを前記共有メモリ内に転送する転送工程を実行させ、
    　前記出力工程は、
    　前記転送工程によって前記揮発性メモリに格納されているデータが前記共有メモリに転送された後、前記揮発性メモリへの電力供給の停止指示を前記電源回路に出力することを特徴とする請求項１０に記載のデータ復元プログラム。
  12. 　揮発性メモリおよび当該揮発性メモリにアクセスするプロセッサを複数搭載したマルチコアプロセッサにアクセス可能なデータ復元装置であって、
    　前記マルチコアプロセッサ内の複数のプロセッサの中の停止指示を受けたプロセッサおよび当該プロセッサがアクセスする揮発性メモリへの電力供給の停止を検出する停止検出手段と、
    　前記停止検出手段によって電力供給の停止が検出された後、前記停止指示を受けたプロセッサ以外の停止指示を受けていない稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、前記停止指示を受けたプロセッサがアクセスする揮発性メモリに格納されていたデータを、前記稼働中のプロセッサ群がアクセス可能な共有メモリ内に復元する復元手段と、
    　を備えることを特徴とするデータ復元装置。
  13. 　停止検出手段と復元手段とを備え、揮発性メモリおよび当該揮発性メモリにアクセスするプロセッサを複数搭載したマルチコアプロセッサにアクセス可能なコンピュータが、
    　前記停止検出手段において、前記マルチコアプロセッサ内の複数のプロセッサの中の停止指示を受けたプロセッサおよび当該プロセッサがアクセスする揮発性メモリへの電力供給の停止を検出する停止検出工程と、
    　前記復元手段において、前記停止検出工程によって電力供給の停止が検出された後、前記停止指示を受けたプロセッサ以外の停止指示を受けていない稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、前記停止指示を受けたプロセッサがアクセスする揮発性メモリに格納されていたデータを、前記稼働中のプロセッサ群がアクセス可能な共有メモリ内に復元する復元工程と、
    　を実行することを特徴とするデータ復元方法。
PCT/JP2010/061179 2010-06-30 2010-06-30 データ復元プログラム、データ復元装置およびデータ復元方法 WO2012001783A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2010/061179 WO2012001783A1 (ja) 2010-06-30 2010-06-30 データ復元プログラム、データ復元装置およびデータ復元方法
JP2012522388A JP5382220B2 (ja) 2010-06-30 2010-06-30 データ復元プログラム、データ復元装置およびデータ復元方法
EP10854080.8A EP2590083A4 (en) 2010-06-30 2010-06-30 DATA RECOVERY PROGRAM, DATA RESTORE DEVICE, AND DATA RESTORATION METHOD
US13/730,514 US9037808B2 (en) 2010-06-30 2012-12-28 Restoring data using parity when suspending a core of a multicore processor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/061179 WO2012001783A1 (ja) 2010-06-30 2010-06-30 データ復元プログラム、データ復元装置およびデータ復元方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/730,514 Continuation US9037808B2 (en) 2010-06-30 2012-12-28 Restoring data using parity when suspending a core of a multicore processor

Publications (1)

Publication Number Publication Date
WO2012001783A1 true WO2012001783A1 (ja) 2012-01-05

Family

ID=45401538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/061179 WO2012001783A1 (ja) 2010-06-30 2010-06-30 データ復元プログラム、データ復元装置およびデータ復元方法

Country Status (4)

Country Link
US (1) US9037808B2 (ja)
EP (1) EP2590083A4 (ja)
JP (1) JP5382220B2 (ja)
WO (1) WO2012001783A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013207184A (ja) * 2012-03-29 2013-10-07 Nec Computertechno Ltd 半導体集積回路装置、半導体集積回路の制御方法、及び制御パラメータの生成方法
TWI714207B (zh) * 2019-08-13 2020-12-21 智原科技股份有限公司 運用於ｉｃ匯流排的開始與結束偵測裝置與方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2012140867A1 (ja) 2011-04-11 2014-07-28 パナソニック株式会社 情報記録媒体、トラッキング方法及び光情報装置
US9122405B1 (en) * 2013-03-15 2015-09-01 Western Digital Technologies, Inc. Fast initialization of storage device
JP2019003163A (ja) * 2017-06-20 2019-01-10 富士通株式会社 情報処理装置、情報処理方法、及びプログラム
US10824502B2 (en) 2018-08-08 2020-11-03 Micron Technology, Inc. Enhanced codeword for media persistence and diagnostics
US11042213B2 (en) 2019-03-30 2021-06-22 Intel Corporation Autonomous core perimeter for low power processor states

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS62198949A (ja) 1986-02-26 1987-09-02 Nec Corp マルチプロセツサ・システムの動作制御方式
JPH09212416A (ja) 1995-11-30 1997-08-15 Toshiba Corp 計算機システムおよび計算機システムの電力管理方法
JP2005508032A (ja) * 2001-10-22 2005-03-24 サン・マイクロシステムズ・インコーポレーテッド 複数の通信リンクとリモートダイレクトメモリアクセスプロトコルとの統合のための方法および装置
JP2005108224A (ja) 2003-09-29 2005-04-21 Hewlett-Packard Development Co Lp 改良型ｒａｉｄメモリ・システム
JP2008257578A (ja) * 2007-04-06 2008-10-23 Toshiba Corp 情報処理装置、スケジューラおよび情報処理置のスケジュール制御方法
JP2009507324A (ja) 2005-09-02 2009-02-19 メタラム インコーポレイテッド Ｄｒａｍをスタックする方法及び装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5928365A (en) 1995-11-30 1999-07-27 Kabushiki Kaisha Toshiba Computer system using software controlled power management method with respect to the main memory according to a program's main memory utilization states
US6785783B2 (en) 2000-11-30 2004-08-31 International Business Machines Corporation NUMA system with redundant main memory architecture
JP2002215337A (ja) 2001-01-16 2002-08-02 Nec Corp ディスクアレイシステム
JP4082706B2 (ja) * 2005-04-12 2008-04-30 学校法人早稲田大学 マルチプロセッサシステム及びマルチグレイン並列化コンパイラ
US7966451B2 (en) * 2008-02-05 2011-06-21 International Business Machines Corporation Power conservation in a composite array of data storage devices

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS62198949A (ja) 1986-02-26 1987-09-02 Nec Corp マルチプロセツサ・システムの動作制御方式
JPH09212416A (ja) 1995-11-30 1997-08-15 Toshiba Corp 計算機システムおよび計算機システムの電力管理方法
JP2005508032A (ja) * 2001-10-22 2005-03-24 サン・マイクロシステムズ・インコーポレーテッド 複数の通信リンクとリモートダイレクトメモリアクセスプロトコルとの統合のための方法および装置
JP2005108224A (ja) 2003-09-29 2005-04-21 Hewlett-Packard Development Co Lp 改良型ｒａｉｄメモリ・システム
JP2009507324A (ja) 2005-09-02 2009-02-19 メタラム インコーポレイテッド Ｄｒａｍをスタックする方法及び装置
JP2008257578A (ja) * 2007-04-06 2008-10-23 Toshiba Corp 情報処理装置、スケジューラおよび情報処理置のスケジュール制御方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2590083A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013207184A (ja) * 2012-03-29 2013-10-07 Nec Computertechno Ltd 半導体集積回路装置、半導体集積回路の制御方法、及び制御パラメータの生成方法
TWI714207B (zh) * 2019-08-13 2020-12-21 智原科技股份有限公司 運用於ｉｃ匯流排的開始與結束偵測裝置與方法

Also Published As

Publication number Publication date
EP2590083A1 (en) 2013-05-08
EP2590083A4 (en) 2016-04-20
JPWO2012001783A1 (ja) 2013-08-22
US20130124804A1 (en) 2013-05-16
US9037808B2 (en) 2015-05-19
JP5382220B2 (ja) 2014-01-08

Similar Documents

Publication Publication Date Title
JP5382220B2 (ja) データ復元プログラム、データ復元装置およびデータ復元方法
US20070233937A1 (en) Reliability of write operations to a non-volatile memory
US10896089B2 (en) System level data-loss protection using storage device local buffers
TWI636396B (zh) 固態硬碟機架構
US8788880B1 (en) Efficient retry mechanism for solid-state memory failures
US10216578B2 (en) Data storage device for increasing lifetime and RAID system including the same
KR101214206B1 (ko) 저장형 컨트롤러 캐시 오프로드 회로의 성능 및 신뢰성을 최적화하기 위한 시스템
JP4821448B2 (ja) Ｒａｉｄコントローラおよびｒａｉｄ装置
US7882320B2 (en) Multi-processor flash memory storage device and management system
US20050229033A1 (en) Disk array controller and information processing apparatus
US9940201B2 (en) Disk array having mirror configuration and rebuilding method therefor
US8984247B1 (en) Storing and reconstructing mapping table data in a data storage system
US20110010499A1 (en) Storage system, method of controlling storage system, and method of controlling control apparatus
WO2014085702A1 (en) Storage control system with data management mechanism of parity and method of operation thereof
KR20040104391A (ko) 멀티클러스터 스토리지 서브 시스템의 자체 파워 손실 복구
US20080005463A1 (en) Command queue ordering by flipping active write zones
US20070101188A1 (en) Method for establishing stable storage mechanism
US9990134B2 (en) Command tunneling in a hybrid data storage device
CN111857540A (zh) 数据存取方法、装置和计算机程序产品
JP5742908B2 (ja) マルチコアプロセッサシステム、制御方法および制御プログラム
US8375187B1 (en) I/O scheduling for flash drives
WO2018064928A1 (en) Data protection for a cold storage system
JP5176854B2 (ja) ディスクアレイサブシステム、ディスクアレイサブシステムのキャッシュ制御方法、及びプログラム
US20080172387A1 (en) Speeding up traversal of a file system tree
CN1920764A (zh) 具磁盘阵列控制功能的核心逻辑单元及磁盘阵列控制方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10854080

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012522388

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2010854080

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE