JP7590852B2 - Storage control system and storage control method - Google Patents

Description

The present invention relates to a storage control system and a storage control method, and more particularly to a storage control system and a storage control method that executes a prioritized application program at high speed by suppressing cache misses of the prioritized application program that is executed in priority over other application programs.

In recent years, in the development of embedded systems that support industrial electronic control devices, the burden on embedded system software, programs, and application programs has increased due to the need to improve the control performance of the systems, comply with increasingly strict environmental regulations, and add new control calculation processes to accommodate autonomous system control.

For example, in many cases, in autonomous control, rules are set based on the circumstances in which the embedded system is active, and the object to be controlled (e.g., a vehicle) is programmed for normal device operation on the assumption that it will operate in accordance with these rules. When a situation arises that deviates from these rules, emergency control of the object is required to deal with the situation.

However, application programs that are not involved in emergency control consume cache memory, which can result in cache hit misses for priority application programs that are essential for emergency control, making it difficult to speed up priority application programs and ultimately making it impossible to handle emergency control.

JP 2007-200277 A (Patent Document 1) discloses a microcomputer that dummy-executes high-priority processing during periods when the CPU is executing idle processing, placing the high-priority processing program in the instruction cache memory, and then when the high-priority processing is executed at the regular timing, the hit rate is high because the high-priority processing program has already been placed in the instruction cache memory, thereby shortening the execution time of the high-priority processing.

JP 2007-200277 A

To speed up the system, not only the priority application program but also the data needs to be maintained in the cache memory, but the latter is not taken into consideration in the above-mentioned Patent Document 1. For example, even if a priority application program such as a collision avoidance program in an automatic driving car is dummy executed before the normal timing, the situation differs from that during actual emergency control, for example, there are no obstacles in the vicinity that need to be avoided in an emergency, and the input information also differs from the actual information, so as a result, the commands and data required for emergency control cannot be maintained in the cache memory. In the first place, dummy execution does not cover all branches and addresses of the priority application program.

The present invention aims to provide a storage control technology that aims to reduce cache misses during the operation of a priority application program, regardless of the operation timing of the priority application program, thereby achieving faster execution of the priority application program.

To achieve the above object, the present invention provides a data storage control system comprising a plurality of controllers, a first controller among the plurality of controllers executes at least one priority application program that is prioritized over other application programs under a predetermined condition, and a second controller among the plurality of controllers that is a controller other than the first controller maintains data required for execution of the priority application program in a cache memory accessible by the priority application program prior to execution of the priority application program.

According to the present invention, cache misses during the operation of a priority application program can be suppressed regardless of the operation timing of the priority application program, thereby achieving faster operation of the priority application program.

FIG. 2 is a hardware block diagram of the control system according to the first embodiment of the present invention. 1 is a table for explaining a cache management method using an LRU counter. 2 is a functional block diagram of the control system of FIG. 1 . 13 shows an example of a management table as core placement management information. 1 is an example of a management table as management information of data to be maintained. 10 is a flowchart illustrating an example of the operation of a cache maintenance application program. FIG. 2 is a block diagram showing a first manner of maintaining data in a cache memory. FIG. 11 is a block diagram showing a second manner of maintaining data in a cache memory. 11 is a timing chart of a plurality of application programs. FIG. 11 is a functional block diagram of a control system according to a second embodiment. 13 is a maintenance target management table according to the second embodiment. 13 is a maintenance target management table according to the third embodiment. 13 is a flowchart illustrating the operation of a cache maintenance application program according to the third embodiment. 13 is a time chart showing the transition of an application program in which target data is maintained in a cache memory in the third embodiment. FIG. 13 is a functional block diagram of a control system according to a fourth embodiment. 13 illustrates an example of maintenance target management information according to the fourth embodiment. 13 is a flowchart showing the operation of a cache maintenance application program in the fourth embodiment. This is a hardware block diagram of a control system showing an example in which the L1 cache is configured outside the core and within the CPU, similar to the L2 cache. FIG. 11 is a hardware block diagram of a control system showing an example in which both an L1 cache and an L2 cache are configured within each core of a multi-core processor. FIG. 2 is a hardware block diagram of a control system showing an example in which an L3 cache is added within the CPU outside each core in addition to the L1 and L2 caches of FIG. FIG. 20 is a hardware block diagram of the control system showing an example in which an L3 cache is added in the CPU outside each core of the control system of FIG. 19.

The present invention relates to a control system and a control method for controlling the storage of information necessary for executing software, such as data, parameters, and commands. For example, the control system controls the storage of information necessary for driving controlled objects such as automobiles, trains, aircraft, robots, communication devices, network devices, and building facilities. The control system constitutes an entire system together with the controlled object. The control system is a microcomputer, a personal computer, or a server. Note that information necessary for executing software, such as data, parameters, and commands, are collectively referred to as "data" and are described in the claims and in the embodiments.

An embodiment of the control system will be described with reference to the drawings. FIG. 1 shows a hardware block diagram of a control system (control device) 101 equipped with a multi-core processor. The control system 101 includes a CPU 102, a main memory 103, and a peripheral device 104. The CPU 102 is equipped with N cores 105-107 that each execute an application program (task), and each core is provided with an L1 cache 108-110. The cores are an example of a controller as described in the claims. The main memory and the cache memory are each storage resources. In the following embodiments and claims, the application program will be abbreviated to application. Data in the main memory is read and set from a non-portable storage medium such as a HDD or a flash memory drive.

In addition to each core, an L2 cache 111 exists in the CPU 102. The L1 caches 108-110 and the L2 cache 111 form a cache memory. The L1 caches 108-110 and the L2 cache 111 each temporarily hold instructions and data stored in the main memory 103. The L1 caches 108-110 can complete writes and reads in a shorter time than the L2 cache 111. The L2 cache 111 is located between the L1 caches 108-110 and the main memory 103 and has the function of connecting the two. Note that the arrangement of the L1 caches 108-110 and the L2 cache 111 is not limited to the example in FIG. 1, and other forms are also possible, such as a form in which the L1 caches 108-110 are managed together by all cores, or the L2 cache 111 is managed by each core. Other forms will be described later.

The control system 101 communicates with the outside world via the peripheral device 104. For example, as a control unit for an automobile, the control system 101 obtains image data from a camera and detection data from ultrasonic sensors, radar sensors, speed sensors, acceleration sensors, etc. via the peripheral device 104, and transmits control signals to the operating system (brake device, steering device, suspension device, etc.) of the controlled object so as to execute emergency control (collision avoidance, etc.) for the automobile as the controlled object. Note that commands stored in the main memory or cache memory can also be treated as a sequence of 0/1, so as mentioned above, in addition to "data" in the narrow sense, programs and commands are also included in "data" in the broad sense.

The L1 caches 108-110 and the L2 cache 111 store at least a portion of the data stored in the main memory 103. If the required data is not present in the L1 cache, the core reads data from the L2 cache, and if the data is not present in the L2 cache either, it reads data from the main memory 103. The core replaces the data in the L1 cache with the data it reads. The method often used for this replacement is LRU (Least Recently Used). This is a management method in which an LRU counter is provided for each piece of data stored in the cache memory, and the order in which the data was last accessed is managed, so that frequently accessed data is given priority in remaining in the cache memory.

Figure 2 shows an overview of a cache memory management method using an LRU counter. As an example of a management method, Figure 2 shows the full set associative method, which is one of the cache memory implementation methods. In this method, data in the cache memory is managed by TAGs instead of address information. An application references the data at the location where the TAG is hit. For example, when an application reads data, it accesses the L1 cache 108 of core 1 (105) that executes the application, and uses the data if it exists. The application sets the LRU counter of the accessed data to 0, and increments the LRU counters of other data by 1. Note that LRU counters with values greater than the accessed data are not incremented.

If the target data does not exist in the L1 cache 108, the application accesses the L2 cache 111, and uses the data if it exists. The application deletes the data with the largest LRU counter from among the data stored in the L1 cache 108, stores the data read from the L2 cache 111 in the L1 cache 108, sets the LRU counter of that data to 0, and increments the LRU counters of the other data by 1.

When the amount of data stored in the cache memory exceeds the number of lines in the cache memory, the core deletes data from the cache memory. Data deleted from the L1 cache 108 is stored in the L2 cache 111.

If the required data is not present in the L2 cache 111, the application accesses the main memory 103 to obtain the desired data. At this time, the application deletes the data with the largest LRU counter value among the data stored in the L1 cache 108, saves the data read from the main memory 103, sets the LRU counter of that data to 0, and increments the LRU counters of the other data by 1.

Furthermore, the core deletes the data stored in the L2 cache 111 that has the largest LRU counter value, stores the data read from the main memory 103 in the L2 cache 111, sets the LRU counter value of that data to 0, and increments the LRU counter values of the other data by 1.

The application stores the data deleted from the L2 cache 111 in the main memory 103. The application deletes the data with the largest LRU counter among the data stored in the L2 cache 111, stores the data read from the main memory 103, sets the LRU counter of that data to 0, and increments the values of the LRU counters of the other data by 1.

If the access is a write, the application stores the write data in the L1 cache 108. At that time, if the data exists in the L1 cache 108, the application sets the LRU counter of the data to "0" and increments the LRU counters of other data by 1. Even if the value of the LRU counter is larger than that of the accessed data, no increment is performed.

If the write data is not present in the L1 cache 108, the application deletes the data with the largest LRU counter, then stores the write data, sets its LRU counter to "0", and increments the LRU counters of the other data by 1. Data deleted from the cache memory is handled in the same way as when reading data, as described above.

As mentioned above, write data is managed by a method called write-back, but this does not deny the application of a write-through method in which data is written not only to the L1 cache 108 but also to the L2 cache 111 and main memory 103 every time data is written.

There is the set associative method, in which the cache memory is divided and the LRU is managed for each block, and the full set associative method, in which the cache memory is not divided. The basic operation of the LRU counter is the same for both. The control system in Figure 1 can employ any of the full set associative method, the set associative method, and the direct map method.

In addition to LRU, methods for managing data replacement in cache memory include round robin and random, but are not limited to any of these. The line size of cache memory is usually 32 to 64 bytes, and the size is not limited.

If data required by an application is not present in the L1 caches 108-110 and the L2 cache 111, and the application requires access to the main memory 103 for a large amount of data, significant delays in the execution of the application will occur. Therefore, it is preferable to maintain data required by applications that must be processed quickly in emergencies (priority applications) in the L1 caches 108-110 and/or the L2 cache 111 as much as possible. This will be explained based on FIG. 3, which is a functional block diagram of the control system.

Figure 3 shows the software configuration inside CPU 102 and part of the data structure in main memory 103. CPU 102 runs a mixture of priority applications 301, which should be executed with priority when necessary, for example in an emergency, and other applications (normal applications) 302, on core 1 (105). A priority application is, for example, an application with a relatively high priority, and a normal application is an application with a relatively low to medium priority. Priority application 301 may be called a high priority application, and normal application 302 may be called a low priority application.

Furthermore, the CPU 102 operates the scheduling module 303 in one or more cores other than the core 1 (105). FIG. 3 shows that the scheduling module 303 is executed in the core 2 (106). The scheduling module 303 controls the timing of starting and suspending the operation of each of the multiple applications. In other words, the scheduling module 303 controls the timing of operation of the priority application 301, the normal application 302, and the cache maintenance application 304 (described below) of the core 1.

The scheduling module 303, under a predetermined condition, for example, in an emergency, causes core 1 to suspend normal application 302 even while it is running, and executes priority application 301 with priority. The scheduling module 303 can know the implementation form of applications for each core based on core placement management information 309 described below. Note that "module" means a function executed by software. "Module" may be replaced with other terms such as "means," "function," "element," "circuit," or "part." A module may be realized by hardware, or by a combination of software and hardware. Which application is placed on which core may be set or changed as appropriate according to the load of the core.

Based on the core allocation management information 309, the scheduling module 303 runs the cache maintenance application 304 on a core (core 2) other than the core 1 on which the priority application 301 and the normal application 302 are running. FIG. 4 shows a management table as the core allocation management information 309. The core allocation management information 309 specifies the relationship between the type of application and the core that executes the application. The core allocation management information 309 is stored in the main memory 103 of the control system 101. The core allocation management information 309 may be registered in the main memory 103 by the administrator of the control system 101.

The cache maintenance application 304 maintains, stores, registers, memorizes, holds, retains, or sets in advance in the cache memory the data required by the priority application 301 (data to be maintained) based on the maintenance target management information 308 so that the priority application 301 does not experience a cache hit miss in an emergency, causing operational delays. This operation of the cache maintenance application 304 is referred to as "cache maintenance." The maintenance target management information 308 is recorded in the main memory 103.

As shown in FIG. 3, the cache maintenance application 304 includes a data access module 306 and a maintenance target management module 307. The maintenance target management module 307 references the maintenance target management information 308 in the main memory 103, passes the reference information to the data access module 306, and the data access module 306 accesses the cache memory and stores the maintenance target data in the cache memory. The cache memory in which the data is stored may be at least one of the L1 cache 108, the L2 cache 111, and the L1 cache 108. In short, it is sufficient that the cache memory can be accessed by the priority application 301.

The cache maintenance application 304 may be continuously executed, for example, by a timer interrupt process. Although the cache maintenance application 304 is not prevented from being executed while the priority application 301 is running, the scheduling module 303 may suspend the cache maintenance application 304 while the priority application 301 is running in order to prevent conflicts caused by simultaneous access to the same data, which may cause delays in the operation of the priority application.

In core 2, the scheduling module 303 operates the cache maintenance application 304 with priority. The scheduling module 303 can run other applications 305 while the cache maintenance application 304 is not operating. The scheduling module 303 may always operate the cache maintenance application 304 with high priority. The scheduling module 303 may also operate the cache maintenance application 304 during spare time when the other applications 305 are not operating, and furthermore, the scheduling module 303 may operate the cache maintenance application 304 periodically.

Figure 5 shows an example of a management table as management information for data to be maintained (maintenance target management information 308). The management table records the target number (entry), the main memory address where the data is stored, and the variable type of the data. This management information allows the data access module 306 to identify the data to be maintained.

Since the data required by the priority application 301 is known in advance, the maintenance target management module 307 can set (register) the maintenance target data in advance in the main memory 103 as maintenance target management information 308, and can also update this. The data access module 306 accesses the main memory 103 based on the maintenance target management information 308, retrieves the data, and records the data in the cache memory.

The cache maintenance application 304 will now be described in detail. FIG. 6 is a flowchart illustrating an example of the operation of the cache maintenance application 304. The cache maintenance application 304 executes the maintenance target management module 307 to determine the target to be maintained, and then causes the data access module 306 to perform cache maintenance.

The maintenance target management module 307 holds the selection number for selecting the maintenance target as a variable, and sets this to 0 after the flowchart is started (S401). After that, the maintenance target management module 307 references the portion where the selection number matches the target number in the maintenance target management table (maintenance target management information 308), and obtains the address and data type information of the target (S402).

Based on the acquired information, the data access module 306 specifies the target data type and address and performs data access (S403). The data access module 306 stores data from the main memory 103 to the L1 cache or L2 cache by data access, and updates the LRU counters of these cache memories to ensure that the target data is maintained in the cache memory so that data required by the priority application 301 is not deleted from the cache memory when the priority application 301 is executed. Next, the maintenance target management module 307 increments the selection number by 1 (S404).

When the value of the selection number reaches the same number as the number of cache maintenance targets, that is, when the data access module 306 has finished accessing all the maintenance targets (S405: Yes), the data access module 306 sets the selection number to 0. If the value of the selection number has not reached the number of cache maintenance targets (S405: No), step S407 checks whether the end sequence has been entered, and if this is affirmative, the flowchart ends (S407: Yes). If step S407 determines No, the process returns to step S402 (S407: No). According to the flowchart in FIG. 4, all maintenance target data registered in the management table 308 is set in the cache memory, and it is possible to prevent cache hit misses even if the priority application 301 suddenly operates.

The management of the end of a flowchart is not particularly limited, and may be a management method using a flag, or a mechanism in which the maintenance target management module 307 receives a signal such as a kill signal or pthread_cancel and calls a cancel handler. In addition, the data size may be registered in the maintenance target management information 308 instead of the data type, and the data access module 306 may specify the size regardless of the variable type such as memcopy to read and write data.

The data access mentioned above (Figure 6: S403) will be explained in more detail. Data access by the data access module 306 includes reading and writing. Data reading is achieved by referencing using an if statement or copying to the zero register, etc. Although it depends on the programming language, there are commands such as the load command when an assembly can be directly specified.

In addition, for example, the prefetch command implemented in ARM CPUs can also achieve the same effect as reading. The line size of cache memory is usually 32 to 64 bytes, and there is no need to access all the data stored in a line of cache memory. By accessing one piece of data per line, it is possible to maintain the cache of data stored in the same line.

Data writing is achieved by writing the same data to the target itself, for example in the form target_data = target_data + 0;. If the assembly can be specified directly, it can also be done using the store command.

Maintaining data in cache memory based on data access (S403) includes registering the data to be maintained in the L1 cache 109 and/or the L2 cache 111. For example, in FIG. 7, the data access module 306 updates the LRU counter if the data to be maintained is present in the L1 cache 109, and if the data is not present in the L1 cache 109 but is present in the L2 cache 111, reads the data from the L2 cache, updates the LRU counter, and stores the data. If the data is not present in the L2 cache 111 either, the data access module 306 reads the data from the main memory 103, updates the LRU counter, and stores the data in the L2 cache 111 (S1).

As a result, it is possible to create a state in which the data required by the priority application 301 is maintained at least in the L2 cache 111 before the priority application 301 operates. Note that although the L2 cache 111 requires more time to access than the L1 cache 109, it can be said that the load on the cache maintenance application 304 is small.

Also, as shown in FIG. 8, the data access module 306 can store the data to be maintained in the L1 cache 109 by reading the data to be maintained from the main memory 103 and writing the data to the same address in the L1 cache 109 (S2).

Meanwhile, a specific application in core 1 can read the data to be maintained from the L1 cache 109 in core 2 using the snoop function, and maintain the data in the L1 cache 108 (S3). Although the load on the cache maintenance application 304 increases due to the snoop function, the priority application 301 can access the data to be maintained in the L1 cache 108 of its own core 1 (105), improving real-time performance when the priority application 301 is executed. Depending on the cache implementation method and application configuration, it may be difficult to maintain the target data in the L2 cache 111, so it is desirable to store the data to be maintained in the L1 cache 109.

Figure 9 shows a comparison of timing charts between the mode in which core 2 is executing cache maintenance application 304 (Figure 3) and a conventional mode in which cache application 304 is not added. The upper part of Figure 9 shows the latter chart, and the lower part of Figure 9 shows the former chart. The vertical axis of Figure 9 indicates the priority of the application, and the horizontal axis indicates the passage of time. The direction of the arrow on the vertical axis indicates higher priority. As already mentioned, 301 is a priority application, and 302 is a normal application, both of which belong to core 1. As already mentioned, 304 is a cache maintenance application.

"H" in Figure 9 is the difference between the time required for the priority application 301 in the former and the time required for the priority application 301 in the latter. In the latter, since the cache maintenance application 304 does not exist in core 2, this becomes overhead and increases the time from the start to the end of the priority application 301 by the time width indicated by H.

Conventionally, if normal application 302 uses up a huge amount of data and the cache becomes full, data related to priority application 301 is deleted from the cache memory, which leads to delays in priority application 301 and its real-time performance is not guaranteed. By running cache maintenance application 304 in a core other than the core in which priority application 301 and other applications 302 coexist, all data (commands and data) that priority application 301 may use can be maintained in the cache memory without interfering with the priority processing of priority application 301.

As in the conventional example described above, even if a priority application is executed in a non-emergency to prevent a cache miss for the priority application, the input values for the priority application during emergency control are different, so ultimately, when emergency control becomes necessary, the commands and data required for the priority application cannot be maintained in the cache.

On the other hand, according to the embodiment described above, the cache maintenance application 304 can maintain the commands and data required for the priority application in the cache memory until just before the emergency occurs. The control system of FIG. 1 can be applied to various technical fields requiring emergency control, such as automatic driving of automobiles, power supply unit control, and robot control.

One method of speeding up applications in a multi-core control system is to port single-core applications, but when running a group of programs made for a single core on a multi-core, there is a risk of deadlocks between tasks or bugs being induced due to changes in execution timing, making it necessary to redesign and verify the programs. In contrast, according to the embodiment described above, it is possible to speed up priority applications without the need for this type of response.

Next, the second embodiment will be described. FIG. 10 is a functional block diagram of a control system according to the second embodiment, and FIG. 11 is maintenance target management information 308 according to the second embodiment. The second embodiment differs from the first embodiment in that the cache maintenance application 304 includes a maintenance request management module 901. In response to a request from the priority application 301, the maintenance request management module 901 adds, changes, or deletes an application as the destination of the maintenance target data in the maintenance target management information 308 via the maintenance target management module 307.

The name of this application is registered in the maintenance target management information 308 in Figure 11. The request contents include the application ID, the number of data items to be maintained, the address of each piece of data to be maintained, and the variable type. The application ID may be changed to a thread ID, process ID, or the like, depending on the form in which the application is implemented on core 1. The variable type of the data to be maintained may be replaced with the size of the data.

When a change in circumstances means that it is no longer necessary to maintain the data to be maintained in the cache memory, the priority application 301 may be able to cancel the cache maintenance. The maintenance request management module 901 receives a cancellation request from the priority application 301, and deletes the information of the application related to the cancellation request from the maintenance target management information 308 via the maintenance target management module 307. The contents of the cancellation request include the application ID, the number of data to be canceled, and the address and variable type of each of the data to be canceled.

To simplify data specification at the time of cancellation, the maintenance request management module 901 may generate a label associated with the data group to be maintained at the time of the request, return the label to the requesting application, and specify the label at the time of cancellation. Furthermore, to prevent the normal application 302 from erroneously canceling the request, the maintenance request management module 901 may adopt a format that rejects cancellation notifications from applications other than the priority application 301, or a format that specifies an application that can accept cancellation notifications.

According to the second embodiment, the priority application to be accelerated can be changed from among multiple priority applications in response to changes in the system situation. For example, in an autonomous driving system for an automobile, the applications that are necessary or important may be different in a mode that supports manual driving by the driver and an autonomous driving mode in which the system is driving. This is not limited to automobiles, but in any system in which the applications that require real-time performance change due to changes in the situation or mode transitions, changing the cache maintenance target at the request of the application makes it possible to accelerate the appropriate application according to the situation.

Next, a third embodiment of the control system will be described. The third embodiment is characterized in that the order and frequency of storing the target data of each of the multiple priority applications 301 in the cache memory is determined based on the priority of the multiple priority applications 301. When there is a large amount of target data to be maintained in the cache memory, such as when there are multiple priority applications, it may not be possible to store all of the data in the cache memory. Therefore, the maintenance target management module 307 (Figures 3 and 10) determines, judges, or selects the priority application whose target data should be maintained in the cache memory, for example, according to the priority of each of the multiple priority applications. This will be described using Figures 12 to 14.

Figure 12 is an example of the maintenance target management information 308 according to the third embodiment. The priority of the priority application is added to this management table 308. Figure 13 is a flowchart explaining the operation of the cache maintenance application 304. Figure 14 is a time chart showing the transition of applications whose target data are maintained in the cache memory by the cache maintenance application 304.

As shown in FIG. 12, the maintenance target management information 308 includes the application priority, index, target number, and continuous maintenance number, and links each data item to the application by a tag (index). The maintenance target management information 308 holds the maintenance number and a selection number for each target application.

As shown in FIG. 13, first, the maintenance target management module 307 sets the maintenance count and each selection number to 0 (S1201). After that, the maintenance target management module 307 compares the priorities between the target applications managed in the maintenance target management information 308 (FIG. 12), and determines the continuous maintenance count for each application according to the priority ratio (S1202).

As shown in FIG. 12, when the priority ratio between applications (App_A:App_B) is 2:1, the maintenance target management module 307 sets the ratio of the number of targets for continuous cache maintenance for application A and application B to 2:1, the same as the priority ratio. Then, the data access module 306 selects applications in order of priority (S1203).

The data access module 306 references the index of the selected application, selects data from the selected application that matches the selection number (S1204), and obtains the address and variable type information of the target data (S1205). The data access module 306 accesses the data based on the obtained data information (S1206).

The data access module 306 increments the maintenance count and the selection number by 1 (S1207), and if the selection number reaches the target number of selected applications (S1208: Yes), resets the selection number to 0 (S1209). If the selection number has not reached the target number of selected applications, the process proceeds directly to the next step (S1208: No).

If the maintenance count reaches the continuous maintenance count of the selected application (S1210: Yes), the data access module 306 changes the selected application to the application of the next priority (S1211). If the maintenance count has not reached the continuous maintenance count of the selected application, the cache maintenance application 304 proceeds directly to the next step (S1210: No).

Then, the data access module 306 checks whether the system is in a shutdown sequence, and if so, shuts down the system (S1212: Yes). If the system is not shutting down, the cache maintenance application 304 returns to S1204 and repeats S1204 to S1212 until the system is shut down (S1212: No).

As shown in FIG. 14, the data access module 306 accesses all of the data to be maintained for App_A (application A), and then accesses part of the data to be maintained for App_B (application B). Next, the cache maintenance application 304 returns to maintaining data for App_A, and when this is completed, continues maintaining the remaining data for App_B. This process is repeated thereafter. The ratio between application A and application B may be determined by the time from the occurrence of an event to the deadline, frequency, etc., regardless of the priority of the applications. Furthermore, the continuous maintenance count may be replaced with the continuous maintenance time.

According to the third embodiment, by controlling the order and frequency of storing data to be maintained in the cache of an application based on the priority of the application, even if there are multiple priority applications, it is possible to hold data to be maintained in the cache memory with priority given to the application with the highest importance. Note that data maintenance in the cache and memory may be performed by setting priority, etc., between multiple data to be maintained for the same application.

Next, the fourth embodiment will be described. This embodiment is characterized in that when there are multiple applications for which data should be maintained in the cache memory, the priority of the order of data maintenance among the multiple applications is determined based on the time it takes for the application to start up. Figure 15 is a functional block diagram of a control system according to the fourth embodiment. Figure 16 shows an example of maintenance target management information 308 according to the fourth embodiment. Figure 17 is a flowchart showing the operation of a cache maintenance application 304 in the fourth embodiment.

The cache maintenance application 304 includes a cycle/time management module 1401 and a timer setting module 1402 in addition to the functional blocks of the control system according to the second embodiment described above. As shown in the maintenance target management information 308 in FIG. 16, the cycle/time management module 1401 manages, for each application, the application execution cycle and the time until each application is started based on the cycle and the time.

The cycle/time management module 1401 first updates the next startup time from the cycle and previous startup time of each application, and selects the application with the closest startup time (S1601). Thereafter, the data access module 306 acquires the data information to be maintained for the selected application, as in the third embodiment (S1602), and performs data access (S1603). This is repeated until the system is shut down (S1604).

When selecting a specific application from among multiple applications, the cycle/time management module 1401 may select an application that can complete cache maintenance before the selected application is launched, based on the time required for cache maintenance. Also, instead of constantly running the cache maintenance application 304, the startup time required for maintenance may be calculated from the next startup time of the target application, and the timer setting function 1402 may be used to set the timer 1403, thereby controlling the operation time of the cache maintenance application.

According to the fourth embodiment, the order of cache maintenance for multiple applications is determined based on the next start time of each of the multiple applications to be cached, i.e., the drive timing of each application, thereby enabling applications with close execution timing to be prioritized and speeded up. In addition, by managing the drive timing using the cache maintenance time and a timer, it is possible to keep the load on the cache maintenance application 304 to a necessary minimum.

Next, another example of the hardware configuration of the control system according to the present invention is shown in the drawings. FIG. 18 is a block diagram showing an example in which the L1 cache 108 is configured in the CPU outside the core, similar to the L2 cache 111. FIG. 19 is a block diagram showing an example in which both the L1 cache 108 and the L2 cache 111 are configured in each core of a multi-core. FIG. 20 is a block diagram showing an example in which an L3 cache 117 is added in the CPU 102 outside each core, in addition to the L1 cache 108 and the L2 cache 111 in FIG. 1. FIG. 21 is a block diagram showing an example in which an L3 cache 117 is added in the CPU 102 outside each core of the control system in FIG. 19. In a form in which the CPU 102 has an L3 cache, the data to be maintained may be maintained in the L3 cache 117.

101 Control system 102 CPU
103 Main memory 104 Peripheral device 105 Core 1
106 Core 2
107 Core N
108 L1 cache (in core 1)
109 L1 cache (in core 2)
110 L1 cache (in core N)
111 L2 cache 301 Priority application 302 Normal application 303 Scheduling module 304 Cache maintenance application 305 Other application 306 Memory access module 307 Maintenance target management module 308 Maintenance target management information 309 Core allocation management information 901 Maintenance request management module 1401 Period/time management module 1402 Timer setting module 1403 Timer

Claims (9)

A data storage control system, comprising:
With multiple controllers,
a first controller of the plurality of controllers executes at least one priority application that is prioritized over other applications under a predetermined condition;
a second controller, which is a controller other than the first controller among the plurality of controllers, maintains data required for execution of the priority application in a cache memory accessible by the priority application before execution of the priority application;
the second controller continues to maintain the necessary data in the cache memory from before the priority application is executed, and suspends the maintenance of the necessary data at a timing when the priority application is started;
Storage control system. It has a main memory,
the first controller and the second controller are each a core of a multi-core CPU,
the main memory has management information for the necessary data;
the second controller maintains the necessary data in the cache memory based on the management information;
2. The storage control system according to claim 1. the cache memory includes an L1 cache and an L2 cache;
the second controller reads the necessary data from the main memory and stores the necessary data in the L1 cache and/or the L2 cache;
3. The storage control system according to claim 2. The first controller and the second controller each include the L1 cache, and the second controller maintains the necessary data stored in its own L1 cache in the L1 cache of the first controller via the L2 cache.
4. The storage control system according to claim 3. the first controller is capable of executing a plurality of applications as the priority applications;
the main memory has management information that associates the necessary data with each of the plurality of applications;
the second controller updates the management information based on a request from at least one application of the plurality of applications as the priority application.
2. The storage control system according to claim 1. the second controller deletes the application that issued the request from the management information;
6. The storage control system according to claim 5 . the first controller is capable of executing a plurality of applications as the priority applications;
the main memory has management information that associates the necessary data with each of the plurality of applications;
the second controller maintains the necessary data in the cache memory in a manner that prioritizes an application having a higher priority in accordance with the priority of each of the plurality of applications as the priority applications;
3. The storage control system according to claim 2 . the first controller is capable of executing a plurality of applications as the priority applications;
the main memory has management information that associates the necessary data with each of the plurality of applications;
the second controller determines whether it is appropriate to maintain the necessary data for the plurality of applications in the cache memory in accordance with a time period required for each of the plurality of applications as the priority applications to be started.
3. The storage control system according to claim 2 . A storage control method in which a plurality of controllers executes control for storing data, comprising:
a first controller of the plurality of controllers executes at least one priority application that is prioritized over other applications under a predetermined condition;
a second controller, which is a controller other than the first controller among the plurality of controllers, maintains data required for execution of the priority application in a cache memory accessible by the priority application before execution of the priority application;
the second controller continues to maintain the necessary data in the cache memory from before the priority application is executed, and suspends the maintenance of the necessary data at a timing when the priority application is started;
Storage control method.

Images