Multi-core real-time operating systems and their task scheduling methods, electronic devices

Abstract

This application discloses a multi-core real-time operating system and its task scheduling method, as well as an electronic device, relating to the field of embedded real-time operating system technology. The task scheduling method for the multi-core real-time operating system includes: acquiring the power consumption and load of each core in the multi-core real-time operating system, and determining whether the power consumption of each core exceeds a preset power consumption threshold; if there is a high-power core with power consumption exceeding the preset power consumption threshold, then based on the power consumption and load of each core, determining a low-power, lightly loaded core among the cores, and sending an interrupt request to the high-power core to interrupt its operation; after interrupting the high-power core, acquiring the transferable tasks among the tasks to be executed in the high-power core, and migrating the transferable tasks to the low-power, lightly loaded core. This application can reduce the power consumption of the multi-core real-time operating system while ensuring its task execution efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded multi-core real-time operating system, and particularly relates to a multi-core real-time operating system and a task scheduling method thereof and an electronic device. BACKGROUND

[0002] At present, a single-core level tickless mechanism is usually relied on to realize management of a multi-core real-time operating system. However, this management mode only focuses on the idle state of a single core, which is likely to cause low-priority tasks such as background tasks in the multi-core real-time operating system to be scattered and scheduled to high-power cores. As a result, even if the load of these tasks is light, the high-power cores still need to maintain an active state to support task running, thereby causing the overall power consumption of the multi-core real-time operating system to be high. SUMMARY

[0003] The main purpose of the present application is to provide a multi-core real-time operating system and a task scheduling method thereof and an electronic device, aiming to guarantee the task execution efficiency of the multi-core real-time operating system while reducing the power consumption of the multi-core real-time operating system.

[0004] To achieve the above purpose, the present application further provides a task scheduling method of a multi-core real-time operating system, which comprises:

[0005] obtaining the power consumption and load of each core in the multi-core real-time operating system and judging whether the power consumption of each core is greater than a preset power consumption threshold;

[0006] if there is a high-power core with power consumption greater than the preset power consumption threshold in each core, determining a low-power light-load core in each core based on the power consumption and load of each core, and sending an interrupt request to the high-power core to interrupt the running of the high-power core;

[0007] after interrupting the running of the high-power core, obtaining a migratable task in each to-be-executed task in the high-power core and migrating the migratable task to the low-power light-load core.

[0008] In an embodiment, the step of obtaining the migratable task in each to-be-executed task in the high-power core comprises:

[0009] obtaining the task type of each to-be-executed task in the high-power core;

[0010] taking a to-be-executed task with a non-real-time task type in each to-be-executed task as the migratable task.

[0011] In an embodiment, each core comprises a high-priority queue, an earliest deadline first queue and a time slice queue; the method further comprises:

[0012] In the initialization process of the multi-core real-time operating system, for any one core in the multi-core real-time operating system, according to task data of each to-be-executed task in the core, a target queue to which each to-be-executed task in the core belongs is determined from the high-priority queue, the earliest deadline first queue and the time slice queue;

[0013] Each to-be-executed task in the core is inserted into the target queue to which the to-be-executed task belongs;

[0014] After the multi-core real-time operating system completes initialization and enters a core scheduling process, the core is controlled to execute tasks in the high-priority queue, the earliest deadline first queue and the time slice queue in turn based on a task scheduling strategy corresponding to each of the high-priority queue, the earliest deadline first queue and the time slice queue.

[0015] In an embodiment, the step of controlling the core to execute tasks in the time slice queue based on the task scheduling strategy corresponding to the time slice queue comprises:

[0016] detecting whether there are multiple short-time tasks among each to-be-executed task in the time slice queue of the core;

[0017] If yes, each short-time task is packaged to obtain a task package;

[0018] The core is controlled to execute each task in the task package simultaneously.

[0019] In an embodiment, the step of packaging each short-time task to obtain a task package comprises:

[0020] According to task data of each short-time task, it is determined whether there is data conflict between each short-time task and another short-time task;

[0021] If there is no data conflict between each short-time task and another short-time task, each short-time task is packaged to obtain the task package;

[0022] If there is data conflict between at least two short-time tasks among each short-time task, each task without data conflict between the at least two short-time tasks is selected as a target task, and each target task is packaged to obtain the task package.

[0023] In an embodiment, the method further comprises:

[0024] In the case that there is no to-be-executed task in the high-priority queue of the core, a sleep decision factor of the core is obtained; the sleep decision factor comprises a task type label of each to-be-executed task in the core and / or a sleep duration of the core;

[0025] determining a target sleep mode of the core according to the sleep decision factor;

[0026] controlling the core to enter the target sleep mode.

[0027] In an embodiment, before the step of controlling the core to enter the target sleep mode, the method further comprises:

[0028] adjusting a working parameter of the core according to the sleep duration; the working parameter comprises core frequency and / or working voltage;

[0029] controlling the core to enter the target sleep mode after adjusting the working parameter of the core.

[0030] In an embodiment, the method further comprises:

[0031] detecting task execution states of the cores during running of the multi-core real-time operating system;

[0032] if a blocked core in a blocked state is detected in the cores, obtaining task data of a next pre-executed task in the blocked core, and loading the task data into a data cache area of the blocked core.

[0033] In addition, to achieve the above object, the present application also provides a multi-core real-time operating system, which comprises:

[0034] a data monitoring module, configured to obtain power consumption and load of the cores in the multi-core real-time operating system;

[0035] a scheduling controller, configured to judge whether the power consumption of the cores is greater than a preset power consumption threshold; if a high-power consumption core whose power consumption is greater than the preset power consumption threshold exists in the cores, determine a low-power consumption and light-load core in the cores based on the power consumption and load of the cores, and send an interrupt request to the high-power consumption core to interrupt running of the high-power consumption core;

[0036] an inter-core coordination module, configured to, after interrupting running of the high-power consumption core, obtain a migratable task in each to-be-executed task in the high-power consumption core, and migrate the migratable task to the low-power consumption and light-load core.

[0037] In addition, to achieve the above object, the present application also provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the computer program is configured to implement steps of a task scheduling method of a multi-core real-time operating system.

[0038] Further, to achieve the above object, the present application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the task scheduling method of the multi-core real-time operating system.

[0039] Further, to achieve the above object, the present application also provides a computer program product, wherein the computer program product comprises a computer program, and the computer program is executed by a processor to implement the steps of the task scheduling method of the multi-core real-time operating system.

[0040] The present application provides a task scheduling method of a multi-core real-time operating system, obtaining the power consumption and load of each core in the multi-core real-time operating system, and determining whether the power consumption of each core is greater than a preset power consumption threshold; if there is a high-power consumption core with power consumption greater than the preset power consumption threshold in each core, determining a low-power consumption and light-load core in each core based on the power consumption and load of each core, and sending an interrupt request to the high-power consumption core to interrupt the operation of the high-power consumption core; after interrupting the operation of the high-power consumption core, obtaining a migratable task in each to-be-executed task in the high-power consumption core, and migrating the migratable task to the low-power consumption and light-load core.

[0041] Therefore, the technical solution provided by the present application can reduce the active time of the high-power consumption core in the multi-core real-time operating system when managing the multi-core real-time operating system. Moreover, since the low-power consumption and light-load core has low power consumption and small load, after taking over the migratable task of the high-power consumption core, it not only does not consume much power, but also can execute the migratable task with stable execution efficiency.

[0042] In summary, the technical solution provided by the present application can reduce the power consumption of the multi-core real-time operating system while ensuring the task execution efficiency of the multi-core real-time operating system. BRIEF DESCRIPTION OF DRAWINGS

[0043] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate one embodiment consistent with the present application and, together with the description, serve to explain the principles of the application.

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0045] Figure 1 A flowchart of the task scheduling method of the multi-core real-time operating system provided by the first embodiment of the present application is shown in the figure.

[0046] Figure 2 The overall implementation flowchart of the task scheduling method of the multi-core real-time operating system provided by the embodiment of the present application is shown in the figure;

[0047] Figure 3 The structural schematic diagram of the multi-core real-time operating system provided by the embodiment of the present application is shown in the figure;

[0048] Figure 4 The implementation principle diagram of the multi-core real-time operating system provided by the embodiment of the present application is shown in the figure;

[0049] Figure 5 The structural schematic diagram of the hardware running environment involved by the embodiment of the present application is shown in the figure.

[0050] The purpose implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings.

[0051] Explanation of the reference signs:

[0052] 10, data monitoring module; 20, scheduling controller; 30, inter-core coordination module; 40, task manager; 50, power consumption management module;

[0053] 101, processing device; 102, read-only memory; 103, storage device; 104, random access memory; 105, bus; 106, input / output interface; 107, input device; 108, output device; 109, communication device. DETAILED DESCRIPTION

[0054] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application, and are not used to limit the present application.

[0055] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings of the specification and specific embodiments.

[0056] At present, the management of the multi-core real-time operating system is usually dependent on the single-core level tickless mechanism. However, this management method only focuses on the idle state of a single core, which is easy to cause the low-priority tasks such as background tasks in the multi-core real-time operating system to be scattered and scheduled to high-power consumption cores. Therefore, even if the load of these tasks is light, the high-power consumption cores still need to maintain an active state to support the task running, resulting in high overall power consumption of the multi-core real-time operating system.

[0057] Based on this, the application provides a task scheduling method of a multi-core real-time operating system, the power consumption and load of each core in the multi-core real-time operating system are acquired, and it is judged whether the power consumption of each core is greater than a preset power consumption threshold; if there is a high-power consumption core with power consumption greater than the preset power consumption threshold in each core, then based on the power consumption and load of each core, a low-power consumption and light-load core in each core is determined, and an interrupt request is sent to the high-power consumption core to interrupt the running of the high-power consumption core; after interrupting the running of the high-power consumption core, the migratable tasks in each to-be-executed task in the high-power consumption core are acquired, and the migratable tasks are migrated to the low-power consumption and light-load core.

[0058] Therefore, the technical scheme provided by the application can reduce the active time of the high-power consumption core in the multi-core real-time operating system when managing the multi-core real-time operating system. Moreover, since the low-power consumption and light-load core has low power consumption and small load, after taking over the migratable tasks of the high-power consumption core, it can execute the migratable tasks with stable execution efficiency without consuming much power consumption.

[0059] In summary, the technical scheme provided by the application can ensure the task execution efficiency of the multi-core real-time operating system while reducing the power consumption of the multi-core real-time operating system.

[0060] The execution subject of the task scheduling method of the multi-core real-time operating system provided by the application can be an electronic device with data processing, network communication and program running functions, or a control system, a control circuit or the like capable of realizing the above functions, and the embodiment does not make specific limitation thereto.

[0061] The following describes each embodiment below by taking an electronic device as an execution subject.

[0062] The application provides a task scheduling method of a multi-core real-time operating system, please refer to Figure 1 , the task scheduling method of the multi-core real-time operating system can include steps S10-S30:

[0063] Step S10, the power consumption and load of each core in the multi-core real-time operating system are acquired, and it is judged whether the power consumption of each core is greater than a preset power consumption threshold;

[0064] It should be noted that the cores in the multi-core real-time operating system are the cores of the multi-core processor used by the multi-core real-time operating system. The sizes of the cores in the multi-core real-time operating system can be the same or different, and the embodiment does not make a specific limitation thereon. For example, assuming that there are large cores and small cores in the multi-core real-time operating system, in the same case, the power consumption consumed by the large core in a unit time is more than that consumed by the small core. The preset power consumption threshold is used as a basis for determining whether the power consumption of the core is high, which can be a default value, or can be flexibly set by the user according to the actual situation, and the embodiment does not make a specific limitation thereon.

[0065] When the power consumption and the load of the cores in the multi-core real-time operating system are obtained, they can be obtained in real time or periodically at a certain time interval, and the embodiment does not make a specific limitation thereon. In addition, it can be limited that the power consumption and the load of the cores are obtained after the power consumption of the cores is stable, so as to avoid misjudgment caused by fluctuations in power consumption.

[0066] When the load of the cores in the multi-core real-time operating system is obtained, the ready queue length, task execution time standard deviation, core frequency and other data of the cores can be obtained first, and then the obtained data is used to determine the load of the cores (for example, the product of the queue length and the task urgency can be used as the load). The ready queue can include but is not limited to a high priority queue, an earliest deadline first (EDF) queue and a time slice queue. When the power consumption of the cores in the multi-core real-time operating system is obtained, the voltage and current of the cores can be obtained first, and then the voltage and current of the cores are used to determine the power consumption of the cores.

[0067] In step S20, if there is a high-power core with power consumption greater than the preset power consumption threshold in the cores, the low-power and light-load core in the cores is determined based on the power consumption and the load of the cores, and an interrupt request is sent to the high-power core to interrupt the running of the high-power core;

[0068] It should be noted that the low-power light-load core is a core with low power consumption and small load among the cores. When determining the low-power light-load core among the cores based on the power consumption and load of the cores, any core with power consumption less than a preset power consumption threshold and load less than a preset load threshold among the cores can be taken as the low-power light-load core; or the core with the smallest power consumption and the smallest load among the cores can be taken as the low-power light-load core; or the core with power consumption less than the preset power consumption threshold and the smallest load among the cores can be taken as the low-power light-load core; or the core with the smallest power consumption and load less than the preset load threshold among the cores can be taken as the low-power light-load core, which is not limited in the embodiment. The preset load threshold as a basis for determining whether the core is light-load can be a default value, or can be flexibly set by the user according to the actual situation. In addition, when there are multiple cores with power consumption less than the preset power consumption threshold and load less than the preset load threshold among the cores, to ensure the task execution efficiency, the idle core (i.e., the core in the idle state) can be selected as the low-power light-load core from the cores with power consumption less than the preset power consumption threshold and load less than the preset load threshold.

[0069] Step S30, after interrupting the running of the high-power core, obtaining the migratable task among the to-be-executed tasks in the high-power core, and migrating the migratable task to the low-power light-load core.

[0070] It should be noted that the migratable task is a task that can be moved to other cores in the high-power core without affecting the overall task execution efficiency of the multi-core real-time operating system.

[0071] In a feasible implementation, the tasks can be divided into real-time tasks and non-real-time tasks according to the task type. For real-time tasks, the core usually adopts a preemptive scheduling mechanism to ensure its priority execution, and this scheduling mode is deeply bound to the running state of the core and the local resources (such as cache data and peripheral interface). If the real-time task is migrated across cores, the context information (such as register state and task priority mark) needs to be re-synchronized and the preemptive relationship needs to be rebuilt, which will introduce uncontrollable delay and affect the response timeliness and execution efficiency of the real-time task. Therefore, the real-time task is usually not suitable for migration between cores. Therefore, step S30 can include steps S31-S32:

[0072] Step S31, obtaining the task type of each to-be-executed task in the high-power core;

[0073] Step S32, taking the to-be-executed task with the task type of non-real-time task among the to-be-executed tasks as the migratable task.

[0074] The task type can be a real-time task and a non-real-time task.

[0075] In another possible implementation, the tasks can be divided into high-priority tasks (such as real-time tasks) and low-priority tasks (such as background tasks) according to task priorities. For high-priority tasks, the core usually adopts a pre-emptive scheduling mechanism to ensure that the high-priority tasks are executed preferentially, and this scheduling mode is deeply bound to the running state of the core, local resources (such as cache data and peripheral interfaces). If the high-priority tasks are migrated across cores, the context information (such as register state and task priority mark) needs to be re-synchronized and the pre-emptive relationship needs to be re-established, which will introduce uncontrollable delay and thus affect the response timeliness and execution efficiency of the high-priority tasks. Therefore, the high-priority tasks are usually not suitable for migration across cores. Thus, the step S30 can include: obtaining task priorities of each to-be-executed task in the high-power core; and regarding each to-be-executed task with a high-priority as a migratable task.

[0076] The task priority can be a high priority and a low priority.

[0077] The above are only two possible implementations of the step S30 provided by the embodiment, and the embodiment does not specifically limit the specific implementation of the step S30.

[0078] As can be known from the above, the technical solution provided by the embodiment can, when managing a multi-core real-time operating system, migrate the migratable tasks in the high-power core in the multi-core real-time operating system to the low-power light-load core, thereby reducing the active time of the high-power core. Moreover, since the low-power light-load core has low power consumption and small load, after the low-power light-load core undertakes the migratable tasks of the high-power core, the low-power light-load core will not consume much power and can execute the migratable tasks with stable execution efficiency.

[0079] Therefore, the technical solution provided by the embodiment can ensure the execution efficiency of the tasks of the multi-core real-time operating system while reducing the power consumption of the multi-core real-time operating system.

[0080] In addition, in other embodiments, all non-real-time tasks or all low-power tasks in the multi-core real-time operating system can be converged to the low-power light-load core to further reduce the power consumption of the multi-core real-time operating system.

[0081] Based on the first embodiment, a second embodiment of the task scheduling method of the multi-core real-time operating system is provided. In the second embodiment, each core includes a high-priority queue, an earliest deadline first queue, and a time slice queue. The task scheduling method of the multi-core real-time operating system can further include steps A10-A30.

[0082] Step A10, for any one core in the multi-core real-time operating system, in the initialization process of the multi-core real-time operating system, according to the task data of each to-be-executed task in the core, determine the target queue of each to-be-executed task in the core in the high priority queue, the earliest deadline priority queue and the time slice queue;

[0083] It should be noted that the task data can include but is not limited to task priority, task deadline, time slice, etc., and the embodiment does not make specific limitation. When determining the target queue of each to-be-executed task in the core in the high priority queue, the earliest deadline priority queue and the time slice queue according to the task data of each to-be-executed task in the core, the target queue of the task with high priority (i.e. the task priority is greater than a certain priority threshold) can be determined as the high priority queue, the target queue of the task with a clear deadline can be determined as the earliest deadline priority queue, and the target queue of the task with priority and no deadline can be determined as the time slice queue.

[0084] Step A20, insert each to-be-executed task in the core into the target queue to which it belongs;

[0085] Step A30, after the multi-core real-time operating system completes the initialization and enters the core scheduling process, the control core executes the tasks in the high priority queue, the earliest deadline priority queue and the time slice queue in turn based on the task scheduling strategy corresponding to each of the high priority queue, the earliest deadline priority queue and the time slice queue.

[0086] It should be noted that after the multi-core real-time operating system completes the initialization, a scheduling function such as Schedule() function can be called to control the multi-core real-time operating system to enter the core scheduling process. The task scheduling strategy corresponding to the high priority queue can be a preemptive scheduling strategy to ensure that the critical task is executed immediately; the task scheduling strategy corresponding to the earliest deadline priority queue can be an earliest deadline priority strategy, which sorts the to-be-executed tasks in the queue according to the deadline to select the task with the earliest deadline to execute. The task scheduling strategy corresponding to the time slice queue can include a time slice round-robin scheduling strategy, which allocates a fixed time slice (such as 10ms) to each to-be-executed task in the queue, so that the task is executed within its own time slice, and when the time slice is exhausted, the task is paused and switched to the end of the queue, allowing the next task to get the opportunity to execute.

[0087] It can be understood that, at present, for embedded real-time operating system (RTOS: Real Time Operation System), that is, real-time operating system, a fixed scheduling strategy (for example, only fixed priority preemption or time slice polling scheduling strategy) is usually used to execute tasks. However, this way is only suitable for the scene where the task priority is fixed, and is not suitable for the scene where the task dynamically changes. Although the dynamic priority algorithm (such as minimum slack time priority, shortest remaining time priority) can adapt to the dynamic change of the task, the calculation complexity is large, and the task switching is frequent, which will affect the task execution efficiency.

[0088] In this embodiment, each core includes a high priority queue, an earliest deadline first queue and a time slice queue. In the initialization process of the multi-core real-time operating system, each task in each core is inserted into the target queue to which it belongs. On this basis, after the multi-core real-time operating system completes the initialization and enters the core scheduling process, each core executes the tasks in the high priority queue, the earliest deadline first queue and the time slice queue based on the task scheduling strategy corresponding to each queue, so that the multi-core real-time operating system considers the real-time and efficiency of task execution.

[0089] In a feasible implementation, to improve the execution efficiency of the tasks in the time slice queue of each core in the multi-core real-time operating system, the task scheduling strategy corresponding to the time slice queue can also include a task aggregation strategy. Therefore, the step of executing the tasks in the time slice queue based on the task scheduling strategy corresponding to the time slice queue can include steps A31-A33.

[0090] Step A31, detecting whether there are multiple short-time tasks in the tasks in the time slice queue of the core;

[0091] It should be noted that the short-time task is a task with an execution time less than a preset time threshold. The preset time threshold, as a basis for determining whether a task is a short-time task, can be a default value or can be flexibly set by the user according to the actual situation, and the embodiment does not make a specific limitation.

[0092] Step A32, if yes, packaging the short-time tasks to obtain a task package;

[0093] In a feasible implementation, step A32 can include steps A321-A323.

[0094] Step A321, determining whether there is a data conflict between the short-time tasks according to the task data of the short-time tasks;

[0095] It should be noted that the data conflict refers to the existence of shared resource competition (such as simultaneous access to the same memory area, the same peripheral interface of the peripheral) or data dependency contradiction (such as task A needs to wait for the output of task B as input, but is arranged to be executed before B) between tasks.

[0096] In step A322, if there is no data conflict between the short-time tasks, the short-time tasks are packaged to obtain a task package.

[0097] In step A323, if there is data conflict between at least two short-time tasks in the short-time tasks, tasks without data conflict are selected from the short-time tasks as target tasks, and the target tasks are packaged to obtain a task package.

[0098] The embodiment further limits that in the process of packaging the short-time tasks, only the short-time tasks without data conflict are packaged, so that when the effective core executes the tasks in the task package, additional synchronization overhead or execution errors caused by data conflict between tasks are avoided, and the execution efficiency and execution effect of the task package are ensured.

[0099] In step A33, the core executes the tasks in the task package simultaneously.

[0100] The embodiment packages the short-time tasks in the time slice queue of each core when the core executes the tasks in the time slice queue, so that the short-time tasks are executed simultaneously, the context switching overhead caused by task switching is reduced, the overall execution efficiency of the time slice queue is improved, and the active time of the core can be reduced to further reduce the power consumption of the multi-core real-time operating system.

[0101] Based on the first embodiment and / or the second embodiment, a third embodiment of the task scheduling method of the multi-core real-time operating system is provided, and in the third embodiment, the task scheduling method of the multi-core real-time operating system can further include steps B10-B30.

[0102] In step B10, if there is no task to be executed in the high-priority queue of the core, a sleep decision factor of the core is obtained; the sleep decision factor includes a task type tag of each task to be executed in the core, and / or a sleep time length of the core.

[0103] It should be noted that the task type tag can record the type of the task, such as a real-time task, a non-real-time task, or a queue type of the task, such as a high-priority task (i.e., a task belonging to a high-priority queue), an earliest deadline first task (i.e., a task belonging to an earliest deadline first queue), and a time slice task (i.e., a task belonging to a time slice queue), and the embodiment is not limited in this regard.

[0104] It can be understood that, in the case that there is no task to be executed in the high priority queue of the core, it indicates that there is no task to be executed immediately at present, and the core can be considered to be on standby for a period of time to reduce power consumption.

[0105] In the process of obtaining the sleep duration of the core, the historical running data of the core can be used to predict the sleep duration of the core, and the wake-up time of the core can also be predicted. The historical running data can include, but is not limited to, the time, duration and wake-up time of the core entering the sleep mode in the past, the task ready time and the task execution time, and the present embodiment does not make specific limitation thereto.

[0106] In the process of predicting the wake-up time of the core by using the historical running data of the core, historical sensor data can be obtained from the historical running data of the core. The historical sensor data includes sub-sensor data corresponding to each historical time. The sub-sensor data whose historical time is earlier than a preset recent time threshold is regarded as long-term data, and the sub-sensor data whose historical time is later than or equal to the preset recent time threshold is regarded as recent data. Each long-term data is weighted according to a preset long-term weight to obtain weighted long-term data, and each recent data is weighted according to a preset recent weight to obtain weighted recent data. The preset long-term weight is less than the preset recent weight. A preset LSTM (Long Short-Term Memory) model is called to predict the wake-up time of the core according to the weighted long-term data and the weighted recent data.

[0107] It should be noted that the historical sensor data is the sensor monitoring module, and the historical sensor data detected by the sensor monitoring module includes sub-sensor data corresponding to each historical time, and each sub-sensor data includes data detected by each sensor in the sensor monitoring module. For example, the historical sensor data can be data in the past n days, and n can be a positive integer. N can be determined based on actual conditions, and the present embodiment does not make specific limitation thereto. The preset recent time threshold can be determined based on actual conditions, and the present embodiment does not make specific limitation thereto. The long-term data is the sub-sensor data whose historical time is earlier than the preset recent time threshold, and the recent data is the sub-sensor data whose historical time is later than or equal to the preset recent time threshold. In other embodiments, the preset recent time threshold can also be determined based on the number of detections. For example, the first m sub-sensor data in the historical sensor data can be determined, and the target historical time with the earliest historical time in the first m sub-sensor data can be regarded as the preset recent time threshold, and m is a positive integer. M can be determined based on actual conditions, and the present embodiment does not make specific limitation thereto.

[0108] In addition, it should be noted that the recent data can more accurately reflect the recent operation of the core than the future data, and therefore, when weighting the future data and the recent data, the preset weight of the recent data is greater than the preset weight of the future data, thereby facilitating the accuracy of the subsequent determination of the wake-up time. The LSTM (Long Short-Term Memory, Long Short-Term Memory Network) is a kind of recurrent neural network. The preset LSTM model can predict the time of the next wake-up core through the weighted future data and the weighted recent data. For example, the weighted future data and the weighted recent data can be input into the preset LSTM model, and the wake-up time of the core is determined through the preset LSTM model.

[0109] The implementation process of calling the preset LSTM model to predict the wake-up time of the core according to the weighted future data and the weighted recent data can include: inputting the weighted future data and the weighted recent data into the preset LSTM model, predicting the predicted time of the wake-up core through the preset LSTM model; obtaining a plurality of historical wake-up intervals of the core from the historical use data, determining an average wake-up interval according to the plurality of historical wake-up intervals; weighting and summing the average wake-up interval and the predicted time according to a first preset smoothing weight of the average wake-up interval and a second preset smoothing weight of the predicted time to obtain the wake-up time.

[0110] It should be noted that the predicted time is the time of waking up the electronic device predicted by the preset LSTM model according to the weighted recent data and the weighted future data. After obtaining the predicted time, the predicted time can be smoothed to obtain the wake-up time, so as to improve the accuracy of the wake-up time. The historical wake-up interval is the time interval between the time of the adjacent two wake-ups of the core, and each historical wake-up interval can be the same or different. The embodiment does not make specific limitation on this. The average wake-up interval is the average value of each historical wake-up interval.

[0111] The sum of the first preset smoothing weight and the second preset smoothing weight is 1, and the specific value of the first preset smoothing weight can be set based on the actual situation. The embodiment does not make specific limitation on this. By weighting and summing the average wake-up interval and the predicted time through the first preset smoothing weight and the second preset smoothing weight, the smoothing processing of the predicted time can be realized, so that the obtained wake-up time is more accurate. The higher the second preset smoothing weight is, the closer the wake-up time is to the predicted time. The lower the second preset smoothing weight is, the closer the wake-up time is to the average wake-up interval.

[0112] The smoothing processing of the predicted time can avoid the sudden change of the finally obtained wake-up time, so as to improve the accuracy of the determination of the wake-up time.

[0113] Step B20, determining the target sleep mode of the core according to the sleep decision factor;

[0114] It should be noted that the sleep decision factor is used to determine the sleep mode required by the core, and the target sleep mode can be a deep sleep mode, a light sleep mode, a low frequency mode, etc., which is not specifically limited in the embodiment. In the deep sleep mode, the core will turn off most peripherals (such as data interface peripherals, high-speed interface peripherals, high-frequency clock sources, etc.), and only keep the wake-up function (such as specific interrupt response function) to minimize standby power consumption; in the light sleep mode, the core will keep part of the peripherals (such as low-power timers, low-speed communication interfaces, etc. and the devices related to “wake-up trigger” or “short initialization time”) running, while keeping the fast wake-up function of the core; in the low frequency mode, the core will run at a lower core frequency to reduce energy consumption while ensuring basic functions.

[0115] In the first feasible implementation, when the sleep decision factor includes the task type tags of the tasks to be executed in the core, and the task type tags are used to record the queue types to which the tasks belong, step B20 can include: determining the proportion of the earliest deadline priority tasks in the core, and if the proportion is greater than a first preset proportion, determining that the target sleep mode of the core is the low frequency mode; if the proportion is less than or equal to the first preset proportion, and greater than a second preset proportion, determining that the target sleep mode of the core is the light sleep mode; and if the proportion is less than or equal to the second preset proportion, determining that the target sleep mode of the core is the deep sleep mode.

[0116] The first preset proportion and the second preset proportion can be a default value, or can be flexibly set by the user according to the actual situation, which is not specifically limited in the embodiment.

[0117] In the second feasible implementation, when the sleep decision factor includes the sleep duration of the core, step B20 can include: if the sleep duration is greater than a first preset duration, determining that the target sleep mode of the core is the deep sleep mode; if the sleep duration is less than or equal to the first preset duration, and greater than a second preset duration, determining that the target sleep mode of the core is the light sleep mode; and if the sleep duration is less than or equal to the second preset duration, determining that the target sleep mode of the core is the low frequency mode.

[0118] The first preset duration and the second preset duration can be a default value, or can be flexibly set by the user according to the actual situation, which is not specifically limited in the embodiment.

[0119] In a third possible implementation, in the case that the sleep decision factor includes the task type label of each task to be executed in the core and the sleep duration of the core, and the task type label is used to record the queue type to which the task belongs, step B20 can include: determining the proportion of the earliest deadline first task in the core, and if the proportion is greater than a first preset proportion and the sleep duration is less than or equal to a second preset duration, determining that the target sleep mode of the core is the low frequency mode; if the proportion is less than or equal to the first preset proportion and greater than a second preset proportion, and the sleep duration is less than or equal to a first preset duration and greater than a second preset duration, determining that the target sleep mode of the core is the light sleep mode; and if the proportion is less than or equal to the second preset proportion and the sleep duration is greater than the first preset duration, determining that the target sleep mode of the core is the deep sleep mode.

[0120] The above are only three possible implementations of step B20 provided by the embodiment, and the embodiment does not specifically limit the specific implementation of step B20.

[0121] In addition, while determining the target sleep mode of the core, the wake-up source of the core also needs to be set synchronously, for example, the RTC (Real-Time Clock) alarm and sensor interrupt can be set as the wake-up source.

[0122] Step B30: controlling the core to enter the target sleep mode.

[0123] In the embodiment, in the case that there is no task to be executed in the high priority queue of the core, the sleep decision factor of the core is combined to adapt to the actual situation of the core, so as to reasonably determine the target sleep mode to which the core is adapted, and then the core is controlled to enter the target sleep mode. Therefore, by using the sleep strategy of on-demand selection, the embodiment can guarantee that the core can respond to subsequent tasks in time, while minimizing the power consumption of the idle period of the core, so as to further reduce the power consumption of the multi-core real-time operating system.

[0124] Based on the third embodiment, a fourth embodiment of the task scheduling method of the multi-core real-time operating system is provided. In the fourth embodiment, in a possible implementation, before step B30, the task scheduling method of the multi-core real-time operating system can further include steps B01-B02.

[0125] Step B01: adjusting the working parameters of the core according to the sleep duration; the working parameters include the core frequency and / or the working voltage;

[0126] It should be noted that adjusting the working parameters of the core according to the sleep duration is essentially to use the DVFS (Dynamic Voltage and Frequency Scaling) mechanism to adjust the working parameters of the core.

[0127] In adjusting the working parameter of the core according to the sleep duration, generally, the working parameter of the core is reduced according to the sleep duration, so as to reduce the power consumption of the core. Specifically, in a feasible implementation, the parameter adjustment amount corresponding to the sleep duration can be obtained as a target parameter adjustment amount based on a preset mapping relationship between the sleep duration and the parameter adjustment amount; and then the working parameter of the core is reduced by subtracting the target parameter adjustment amount from the working parameter of the core. In another feasible implementation, the parameter adjustment coefficient corresponding to the sleep duration can be obtained as a target parameter adjustment coefficient based on a preset mapping relationship between the sleep duration and the parameter adjustment coefficient (the parameter adjustment coefficient is greater than 0 and less than 1); and then the working parameter of the core is reduced by multiplying the target parameter adjustment coefficient with the working parameter of the core. The specific implementation of the present embodiment is not specifically limited to the specific implementation of step B01.

[0128] The mapping relationship between the sleep duration and the parameter adjustment amount, and the mapping relationship between the sleep duration and the parameter adjustment coefficient can be recorded in the form of a relationship table, a relationship curve or a key-value pair, and the present embodiment is not specifically limited thereto.

[0129] Step B02, after adjusting the working parameter of the core, the core is controlled to enter the target sleep mode.

[0130] The present embodiment avoids the instantaneous power fluctuation when the core is directly switched from the active state to the sleep mode by setting that the working parameter of the core needs to be reduced according to the sleep duration of the core before the core enters the target sleep mode, so as to make the core hardware state (such as the power supply module and the clock unit) smoothly transition to the low-power consumption interval, lay a stable low-power consumption foundation for subsequent entering the target sleep mode, and further compress the energy loss of the core in the transition phase while ensuring the safety of mode switching.

[0131] In addition, in other embodiments, different working parameters can be set for different sleep modes, so that the working parameter of the core can be adjusted according to the target sleep mode of the core. Generally, the working parameter of the deep sleep mode is smaller than the working parameter of the light sleep mode, and the working parameter of the light sleep mode is smaller than the working parameter of the low-frequency mode.

[0132] Based on the first embodiment, the second embodiment, the third embodiment and / or the fourth embodiment, the fifth embodiment of the task scheduling method of the multi-core real-time operating system is proposed, and in the fifth embodiment, the task scheduling method of the multi-core real-time operating system can further include steps C10-C20:

[0133] Step C10, detecting the task execution state of each core in the running process of the multi-core real-time operating system;

[0134] It should be noted that the task execution state can be a ready state, a running state and a blocked state.

[0135] In step C20, if it is detected that there is a blocked core in each core with a blocked state of the task execution state, the task data of the next pre-execution task in the blocked core is obtained, and the task data is loaded into the data cache area of the blocked core.

[0136] In the running process of the multi-core real-time operating system, if it is detected that there is a blocked core in each core with a blocked state of the task execution state, the task data of the next pre-execution task in the blocked core is obtained, and the task data is loaded into the data cache area of the blocked core. Therefore, when the blocked core recovers from the blocked state, the next pre-execution task can directly read the required data from the local cache without the need to load from the memory or other storage medium, which greatly shortens the preparation time of the task and improves the task response speed after the recovery of the blocked core. Moreover, by caching the data in advance, the external storage access operation of the core in the task start stage can be reduced, the power consumption and bus occupation caused by data reading are reduced, and the blocked core can immediately and efficiently execute the task after recovery, which not only optimizes the overall response performance of the system, but also indirectly reduces unnecessary energy consumption.

[0137] By way of example, to facilitate understanding of the implementation process of the task scheduling method of the multi-core real-time operating system formed by combining the above embodiments, please refer to Figure 2 , in detail:

[0138] After the multi-core real-time operating system completes the initialization after starting, the core scheduling process is entered; under the core scheduling process, for each core in the multi-core real-time operating system, it is first determined whether there is a task to be executed in the high priority queue of the core, if there is, the task scheduling mechanism corresponding to the high priority queue is used to execute the task in the high priority queue (i.e. high priority task);

[0139] If there is no task to be executed in the high priority queue of the core, it is determined whether there is a task to be executed in the earliest deadline first queue of the core, if there is, the task scheduling mechanism corresponding to the earliest deadline first queue is used to execute the task in the earliest deadline first queue (i.e. EDF task);

[0140] If there is no task to be executed in the earliest deadline first queue of the core, it is determined whether there is a collectable task (i.e. each short-time task without data conflict) in the time slice queue of the core, if there is, each collectable task is executed; if not, the time slice round-robin scheduling strategy is used to execute the task in the time slice queue of the core;

[0141] In the process of executing the task, the task execution state of the core is detected. If the task execution state of the core is a blocking state, the task data of the next pre-execution task in the core can be loaded into the data cache area of the core to realize data prefetching. If the task execution state of the core is a non-blocking state, it can be judged whether the power consumption of the core is greater than a preset power consumption threshold. If yes, the migratable task of the core can be migrated to a low-power light-load core in the multi-core real-time operating system.

[0142] After completing the task migration, it can be detected whether there is a high-priority task in each core in the multi-core real-time operating system (that is, whether each core is idle). If yes, low-power management can be performed on each idle core to determine the target sleep mode required by each idle core to enter and configure the corresponding wake-up source, thereby controlling the corresponding core to enter the sleep mode until the core is awakened.

[0143] It should be noted that the above examples are only used to assist in understanding the present application and do not constitute a limitation on the task scheduling method of the multi-core real-time operating system of the present application.

[0144] The present application also provides a multi-core real-time operating system, please refer to Figure 3 The multi-core real-time operating system can include:

[0145] The data monitoring module 10 is configured to obtain the power consumption and load of each core in the multi-core real-time operating system.

[0146] The scheduling controller 20 is configured to judge whether the power consumption of each core is greater than a preset power consumption threshold. If there is a high-power core with power consumption greater than the preset power consumption threshold in each core, the low-power light-load core in each core is determined based on the power consumption and load of each core, and an interrupt request is sent to the high-power core to interrupt the operation of the high-power core.

[0147] The inter-core coordination module 30 is configured to obtain the migratable task in each to-be-executed task in the high-power core after interrupting the operation of the high-power core, and migrate the migratable task to the low-power light-load core.

[0148] It should be noted that after the data monitoring module 10 obtains the power consumption and load of each core in the multi-core real-time operating system, a power consumption matrix and a load matrix can be generated correspondingly. The data is transmitted to the scheduling controller 20 through the shared memory in the multi-core real-time operating system and by using the inter-core interrupt mechanism.

[0149] In the shared memory, a fixed-size structure array can be allocated. Each element corresponds to the load and power consumption of a core.

[0150] The data monitoring module 10 can update the data in the shared memory by using a synchronization mechanism, for example, a read-write lock or a spin lock can be used to avoid data competition, the data monitoring module 10 can update the data in write mode, and the scheduling controller 20 can acquire the data in read mode, so as to reduce the lock occupation time. When the scheduling controller 20 reads the data, the atomic reading mode can be used for reading.

[0151] The data monitoring module 10 can update the data in the shared memory at a fixed period (for example, 10 ms), and when a load mutation (for example, a sudden increase in the queue length) is detected, the data in the shared memory can be immediately updated.

[0152] In addition, the inter-core interrupt can be set to high priority, so as to ensure fast response during the task execution gap, and over-preemption of the critical task can be avoided.

[0153] In an embodiment, the inter-core coordination module 30 is further configured to:

[0154] acquire the task types of the to-be-executed tasks in the high-power core;

[0155] regard the to-be-executed task whose task type is a non-real-time task as a migratable task.

[0156] In an embodiment, each core includes a high-priority queue, an earliest deadline first queue and a time slice queue; the multi-core real-time operating system further includes a task manager 40, configured to:

[0157] For any core in the multi-core real-time operating system, in the initialization process of the multi-core real-time operating system, according to the task data of the to-be-executed tasks in the core, the target queue to which each to-be-executed task in the core belongs is determined in the high-priority queue, the earliest deadline first queue and the time slice queue;

[0158] insert each to-be-executed task in the core into the target queue to which the to-be-executed task belongs;

[0159] The scheduling controller 20 is further configured to, after the multi-core real-time operating system completes the initialization and enters the core scheduling process, control the core to execute the tasks in the high-priority queue, the earliest deadline first queue and the time slice queue in turn based on the task scheduling strategies corresponding to the high-priority queue, the earliest deadline first queue and the time slice queue respectively.

[0160] In an embodiment, the scheduling controller 20 is further configured to:

[0161] detect whether there are multiple short-time tasks among the to-be-executed tasks in the time slice queue of the core;

[0162] if yes, package the short-time tasks to obtain a task package;

[0163] The control core executes each task in the task package simultaneously.

[0164] In an embodiment, the scheduling controller 20 is further configured to:

[0165] determine, according to the task data of each short-time task, whether there is data conflict between each short-time task;

[0166] if there is no data conflict between each short-time task, package each short-time task to obtain a task package;

[0167] if there is data conflict between at least two short-time tasks in each short-time task, select each task without data conflict from each short-time task as each target task, and package each target task to obtain a task package.

[0168] In an embodiment, the multi-core real-time operating system further comprises a power consumption management module 50 configured to:

[0169] if there is no task to be executed in the high-priority queue of the core, obtain a sleep decision factor of the core; the sleep decision factor comprises a task type tag of each task to be executed in the core, and / or a sleep duration of the core;

[0170] determine a target sleep mode of the core according to the sleep decision factor;

[0171] control the core to enter the target sleep mode.

[0172] In an embodiment, the power consumption management module 50 is further configured to:

[0173] adjust a working parameter of the core according to the sleep duration; the working parameter comprises a core frequency and / or a working voltage;

[0174] after adjusting the working parameter of the core, control the core to enter the target sleep mode.

[0175] In an embodiment, the scheduling controller 20 is further configured to:

[0176] detect a task execution state of each core during the running of the multi-core real-time operating system;

[0177] if it is detected that there is a blocked core with a blocked state in each core, obtain task data of a next pre-execution task in the blocked core, and load the task data into a data cache area of the blocked core.

[0178] For example, the overall implementation principle of the multi-core real-time operating system in the embodiment can refer to Figure 4 , specifically:

[0179] After the scheduling controller 20 sends the core data reading request to the data monitoring module 10, the scheduling controller 20 can determine whether the power consumption of each core is greater than the preset power consumption threshold by using the read data of each core; if it is determined that the core A is a high-power consumption core and the core B is a low-power consumption and light-load core, the scheduling controller 20 can output a migration instruction to the inter-core coordination module 30 to inform the inter-core coordination module 30 to obtain the migratable tasks in each to-be-executed task in the core A and migrate the migratable tasks to the core B; after the migration is completed, the task manager 40 updates the data in the ready queues of the core A and the core B.

[0180] Meanwhile, when it is determined that there is a to-be-executed task in the high-priority queue of the core A and there is no to-be-executed task in the high-priority queue of the core B, the power consumption management module 50 can set the core frequencies of the core A and the core B, for example, the core frequency of the core A can be set to 3 GHz and the core frequency of the core B can be set to 1.5 GHz.

[0181] It should be noted that the above examples are only used to assist in understanding the present application and do not constitute a limitation on the task scheduling method of the multi-core real-time operating system of the present application.

[0182] The multi-core real-time operating system provided by the embodiment of the present application adopts the task scheduling method of the multi-core real-time operating system in the above embodiment, which can reduce the power consumption of the multi-core real-time operating system while ensuring the task execution efficiency of the multi-core real-time operating system. Compared with the prior art, the multi-core real-time operating system provided by the embodiment of the present application has the same beneficial effects as the task scheduling method of the multi-core real-time operating system provided by the above embodiment, and other technical features in the electronic device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0183] The embodiment of the present application also provides an electronic device, which can include at least one processor and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the task scheduling method of the multi-core real-time operating system in the above embodiment.

[0184] The following refers to Figure 5 which shows a structural schematic diagram of an electronic device suitable for implementing the embodiment of the present application. Figure 5 The electronic device shown is only an example and should not impose any limitation on the functions and use range of the embodiment of the present application.

[0185] As Figure 5As shown, the electronic device can include a processing device 101 (e.g., a central processor, a graphics processor, etc.) that can perform various appropriate actions and processes according to programs stored in a read-only memory 102 or loaded from a storage device 103 into a random access memory 104. Various programs and data required for operation of the electronic device are also stored in the random access memory 104. The processing device 101, the read-only memory 102, and the random access memory 104 are connected to each other by a bus 105. An input / output interface 106 is also connected to the bus 105. Generally, the following systems can be connected to the input / output interface 106: input devices 107 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 108 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 103 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 109. The communication device 109 can allow the electronic device to communicate wirelessly or wired with other devices to exchange data. Although the electronic device having various systems is shown in the drawing, it should be understood that all of the illustrated systems are not required to be implemented or possessed. More or less systems can be alternatively implemented or possessed.

[0186] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for performing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by a communication device, or installed from the storage device 103, or installed from the read-only memory 102. When the computer program is executed by the processing device 101, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are performed.

[0187] The electronic device provided by the embodiments of the present disclosure adopts the task scheduling method of the multi-core real-time operating system in the above-mentioned embodiments, which can reduce the power consumption of the multi-core real-time operating system while ensuring the task execution efficiency of the multi-core real-time operating system. Compared with the prior art, the electronic device provided by the embodiments of the present disclosure has the same beneficial effects as the task scheduling method of the multi-core real-time operating system provided by the above-mentioned embodiments, and other technical features in the electronic device are the same as the features disclosed in the above-mentioned embodiment methods, which will not be repeated here.

[0188] It should be understood that parts of the embodiments of the present disclosure can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0189] The above merely provides the specific implementation of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited to this. Any person skilled in the art can easily think of the changes or replacements within the technical range disclosed by the present application, which should be covered in the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application should be subject to the protection scope of the claims above.

[0190] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program capable of running on a processor, and the computer program is used for executing the task scheduling method of the multi-core real-time operating system in the above embodiments.

[0191] The computer readable storage medium provided by the embodiments of the present application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM or flash memory), an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiments, the computer readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, a system or a device. The program code contained in the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), etc., or any suitable combination of the above.

[0192] The above computer readable storage medium can be contained in an electronic device, or can exist separately without being assembled into an electronic device.

[0193] The computer readable storage medium carries one or more programs, when the one or more programs are executed by the electronic device, the electronic device is caused to: acquire power consumption and load of each core in a multi-core real-time operating system, and determine whether the power consumption of each core is greater than a preset power consumption threshold; if there is a high-power consumption core whose power consumption is greater than the preset power consumption threshold among the cores, determine a low-power consumption and light-load core among the cores based on the power consumption and the load of each core, and send an interrupt request to the high-power consumption core to interrupt the running of the high-power consumption core; after interrupting the running of the high-power consumption core, acquire a migratable task in each to-be-executed task in the high-power consumption core, and migrate the migratable task to the low-power consumption and light-load core.

[0194] Computer program code for carrying out operations of the present disclosure can be written in any one or more of a variety of programming languages or combinations of languages including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0195] The flow diagrams and the block diagrams in the drawings are illustrations of possible architectures, functions, and operations for systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0196] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0197] The computer readable storage medium provided by the embodiments of the present application stores computer readable program instructions for executing the task scheduling method of the multi-core real-time operating system, which can reduce the power consumption of the multi-core real-time operating system while ensuring the task execution efficiency of the multi-core real-time operating system. Compared with the prior art, the computer readable storage medium provided by the embodiments of the present application has the same beneficial effects as the task scheduling method of the multi-core real-time operating system provided by the above embodiments, and thus will not be described here.

[0198] The embodiments of the present application further provide a computer program product, which comprises a computer program. When the computer program is executed by a processor, the steps of the task scheduling method of the multi-core real-time operating system are implemented.

[0199] The computer program product provided by the embodiments of the present application can reduce the power consumption of the multi-core real-time operating system while ensuring the task execution efficiency of the multi-core real-time operating system. Compared with the prior art, the computer program product provided by the embodiments of the present application has the same beneficial effects as the task scheduling method of the multi-core real-time operating system provided by the above embodiments, and thus will not be described here.

[0200] The above is only the preferred embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation using the content of the specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A task scheduling method of a multi-core real-time operating system, characterized by, The method comprises: obtaining the power consumption and load of each core in the multi-core real-time operating system, and determining whether the power consumption of each core is greater than a preset power consumption threshold; if there is a high-power consumption core in each core whose power consumption is greater than the preset power consumption threshold, determining a low-power consumption and light load core in each core based on the power consumption and load of each core, and sending an interrupt request to the high-power consumption core to interrupt the operation of the high-power consumption core; after interrupting the operation of the high-power consumption core, obtaining a migratable task in each to-be-executed task in the high-power consumption core, and migrating the migratable task to the low-power consumption and light load core, wherein each core comprises a high-priority queue, an earliest deadline first queue and a time slice queue; for any one core in the multi-core real-time operating system, in the initialization process of the multi-core real-time operating system, according to the task data of each to-be-executed task in the core, determining the target queue to which each to-be-executed task in the core belongs in the high-priority queue, the earliest deadline first queue and the time slice queue; inserting each to-be-executed task in the core into the target queue to which it belongs; after the multi-core real-time operating system completes initialization and enters the core scheduling process, controlling the core to execute the tasks in the high-priority queue, the earliest deadline first queue and the time slice queue in turn based on the task scheduling strategies corresponding to the high-priority queue, the earliest deadline first queue and the time slice queue respectively; wherein the step of controlling the core to execute the tasks in the time slice queue based on the task scheduling strategy corresponding to the time slice queue comprises: detecting whether there are multiple short-time tasks in each to-be-executed task in the time slice queue of the core; if so, determining whether there is data conflict between each short-time task according to the task data of each short-time task; if there is no data conflict between each short-time task, packaging each short-time task to obtain a task package; if there is data conflict between at least two short-time tasks in each short-time task, selecting each task without data conflict from each short-time task as a target task, and packaging each target task to obtain the task package; controlling the core to execute each task in the task package simultaneously; in the case that there is no to-be-executed task in the high-priority queue of the core, obtaining a sleep decision factor of the core; the sleep decision factor comprises a task type label of each to-be-executed task in the core and / or a sleep duration of the core; adjusting the working parameters of the core according to the sleep duration, the working parameters comprising core frequency and / or working voltage; determining a target sleep mode of the core according to the sleep duration, and controlling the core to enter the target sleep mode.

2. The method of claim 1, wherein, The step of obtaining the migratable task in each to-be-executed task in the high-power consumption core comprises: obtaining the task type of each to-be-executed task in the high-power consumption core; regarding each to-be-executed task in each to-be-executed task whose task type is a non-real-time task as the migratable task.

3. The method of claim 1 or 2, wherein, The method further comprises: During running of the multi-core real-time operating system, task execution states of the cores are detected; If a blocked core in a blocked state is detected in the cores, task data of a next pre-execution task in the blocked core is acquired, and the task data is loaded into a data cache area of the blocked core.

4. A multi-core real-time operating system, characterized by The multi-core real-time operating system comprises: A data monitoring module is configured to acquire power consumption and load of each core in the multi-core real-time operating system; A scheduling controller is configured to determine a low-power light-load core in each core based on the power consumption and the load of each core, and send an interrupt request to a high-power core with power consumption greater than a preset power consumption threshold to interrupt running of the high-power core; An inter-core coordination module is configured to acquire a migratable task in each to-be-executed task in the high-power core after interrupting running of the high-power core, and migrate the migratable task to the low-power light-load core, wherein each core comprises a high-priority queue, an earliest deadline first queue and a time slice queue; The multi-core real-time operating system further comprises: For any core in the multi-core real-time operating system, in an initialization process of the multi-core real-time operating system, target queues to which each to-be-executed task in the core belongs are determined according to task data of each to-be-executed task in the core; Each to-be-executed task in the core is inserted into a target queue to which the to-be-executed task belongs; After the multi-core real-time operating system completes initialization and enters a core scheduling process, the core is controlled to execute tasks in the high-priority queue, the earliest deadline first queue and the time slice queue in turn based on task scheduling strategies corresponding to the high-priority queue, the earliest deadline first queue and the time slice queue respectively, wherein controlling the core to execute tasks in the time slice queue based on the task scheduling strategy corresponding to the time slice queue further comprises: detecting whether a plurality of short-time tasks exist in each to-be-executed task in the time slice queue; if yes, determining whether data conflicts exist between each short-time task based on task data of each short-time task; if no data conflicts exist between each short-time task, packaging each short-time task to obtain a task package; if at least two short-time tasks exist in each short-time task and data conflicts exist between the short-time tasks, selecting each task without data conflicts from each short-time task as a target task, and packaging each target task to obtain the task package; and controlling the core to execute each task in the task package simultaneously; The multi-core real-time operating system further comprises: In the case that there is no task to be executed in the high priority queue of the core, a sleep decision factor of the core is acquired; the sleep decision factor comprises a task type label of each task to be executed in the core and / or a sleep duration of the core; according to the sleep duration, a working parameter of the core is adjusted, the working parameter comprising a core frequency and / or a working voltage; according to the sleep duration, a target sleep mode of the core is determined, and the core is controlled to enter the target sleep mode.

5. An electronic device, comprising: The electronic device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the task scheduling method of the multi-core real-time operating system according to any one of claims 1 to 3.

Images