Interrupt-Driven Micro-Scheduler for Multi-Core Task Preemption
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional multi-core system-on-chip architectures face inefficiencies due to the lack of effective preemption management between cores, particularly in scenarios requiring dynamic task prioritization, and the overhead associated with implementing multicore multithreading RTOS or remote procedure calls.
Innovation Solution
A mechanism is introduced to manage task preemption by using a main processor to generate and prioritize task requests, communicate them to an auxiliary processor through a shared memory and interrupt signal, allowing the auxiliary processor to suspend current tasks and execute higher-priority requests efficiently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If a multicore multithreading RTOS is implemented to manage multiple cores, then task scheduling and preemption capabilities are improved, but system size and complexity increase
Solution Approach 1:
The patent extracts the full RTOS scheduling functionality and implements only the essential preemption management features needed for auxiliary processor control. This selective extraction provides task scheduling capability without the overhead of a complete multicore multithreading RTOS, resolving the contradiction between productivity improvement and device complexity reduction.
Solution Approach 2:
The patent applies preemption management locally at the auxiliary processor level rather than implementing a global RTOS across all cores. The main processor generates task requests with priority levels, and the auxiliary processor independently manages preemption based on these priorities, providing localized scheduling capability without system-wide RTOS complexity.
2Productivity
If remote procedure calls are used to offload tasks to auxiliary processors, then processing efficiency is improved, but the ability to manage task preemption deteriorates
Solution Approach 1:
The patent applies preliminary action by having the main processor assign priority levels to task requests before sending them to the auxiliary processor. The auxiliary processor uses these pre-assigned priorities to automatically manage preemption without needing complex runtime negotiation, thus maintaining processing efficiency while enabling preemption management.
Solution Approach 2:
The patent implements feedback through the interrupt signal mechanism. When the auxiliary processor completes a task or needs to preempt, it uses interrupt signals to communicate status back to the main processor, which then adjusts subsequent task assignments based on this feedback, enabling dynamic preemption management alongside RPC-based task offloading.
3Productivity
If a bidirectional hardware component like a mailbox is used for inter-core communication, then task distribution between cores is improved, but the system cannot suspend ongoing tasks to handle higher-priority requests
Solution Approach 1:
The patent applies dynamics by making the auxiliary processor's task execution state changeable based on priority levels. The auxiliary processor can dynamically suspend its current task when a higher-priority task request arrives, and the mailbox mechanism dynamically adapts to support both task distribution and preemption by carrying priority information alongside task requests.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
According to an embodiment, a method (200, 500, 600) for scheduling preemption in a multi-core system is proposed. The method includes generating (202) a plurality of task requests, each task request corresponding to a job to be executed by an auxiliary processor (112, 400) and having a respective priority level; storing the plurality of task requests in a shared memory (104); selecting (204) a first task request from the plurality of task requests stored in the shared memory with a highest priority level; communicating (206) the first task request to the auxiliary processor; suspending (208) an execution of a current task in response to receiving the interrupt signal; retrieving (208) the respective priority level of the first task request; adding (208) the first task request and its respective priority level to an execution queue; and executing (210) a task from the execution queue having a highest priority.