Efficient collaborative task scheduling method based on RSIC-v architecture embedded system

Abstract

The invention relates to an efficient collaborative task scheduling method based on an RSIC-v architecture embedded system, which belongs to the technical field of resource coroutine scheduling, and comprises the following steps: external trigger condition priority: dividing external input requests of the RSIC-v architecture embedded system into two types, i.e., a common type request and an event type request, the event type request is processed preferentially and triggers corresponding task scheduling; efficient state management: introducing a state machine model, and carrying out state management simplification of a coroutine so as to reduce data structure updating and resource consumption during state switching; according to the lightweight context switching mechanism, a user mode coroutine scheduler is designed, scheduling of an operating system is not needed, only necessary register states of a PC and an SP are stored, and the core function of the scheduler is achieved by using an assembly language of an RSIC-V architecture chip instruction set; the method has the beneficial effects that the scheduler performs coroutine scheduling according to the state of the request resource of the task / coroutine.

Description

Technical Field

[0001] The present invention belongs to the technical field of resource coroutine scheduling, and in particular relates to an efficient collaborative task scheduling method based on an RSIC-v architecture embedded system. Background Art

[0002] In embedded systems, task management and scheduling play a critical role in high-concurrency scenarios. Existing task / coroutine scheduling technologies primarily rely on monitoring and responding to I / O events through event-driven mechanisms (such as epoll). However, existing technologies have the following drawbacks:

[0003] 1. Scheduling efficiency bottleneck: In high-concurrency scenarios, there are a large number of coroutines. When selecting the next coroutine to execute, the scheduler often needs to traverse the ready queue, resulting in low scheduling efficiency.

[0004] 2. Complex state management: Coroutine states are diverse (such as ready, sleeping, and waiting). Existing schedulers need to frequently update data structures (such as red-black trees and queues) when switching states, which increases management complexity. Summary of the Invention

[0005] The present invention provides an efficient collaborative task scheduling method based on an RSIC-v architecture embedded system, which is used to solve the technical problem of resource status-based coroutine scheduling. The scheduler schedules the coroutine according to the status of the requested resources of the task / coroutine.

[0006] In order to achieve the above object, the present invention is implemented through the following technical solutions:

[0007] An efficient collaborative task scheduling method based on an RSIC-v architecture embedded system includes the following steps:

[0008] Priority of external trigger conditions: RSIC-v architecture embedded system external input requests are divided into two categories, command type requests and event type requests. Event type requests are processed first and trigger corresponding task scheduling;

[0009] Efficient state management: Introducing a state machine model to simplify coroutine state management, thereby reducing data structure updates and resource consumption during state switching;

[0010] Lightweight context switching mechanism: A user-mode coroutine scheduler is designed that does not require operating system scheduling and only saves the necessary register states of PC and SP. The core functions of the scheduler are implemented using the assembly language of the RSIC-V architecture chip instruction set.

[0011] Optionally, during external request input and external request parsing, requests with illegal task IDs are discarded, and tasks are scheduled based on the FIFO mixed priority mechanism with Event requests taking precedence over Command requests.

[0012] Optionally, the RSIC-v architecture embedded system includes a command queue processing module, an event queue processing module, a state switching management module, and a coroutine management and scheduling module, and each module works collaboratively through a FIFO hybrid priority mechanism.

[0013] Optionally, the state management of the coroutine in the state machine model includes at least Ready, Running, Suspend, and Dead states, and defines the transition rules between each state.

[0014] Optionally, the context switching time of the user-mode coroutine scheduler is reduced from microseconds to nanoseconds, making it compatible with 32-bit / 64-bit RISC-V chip series.

[0015] Optionally, during the initialization phase of the RSIC-v architecture embedded system, the number of concurrent tasks supported is predefined, a unique task ID that remains unchanged during its life cycle is assigned to each task, and the initial state of the task is set to Ready.

[0016] Optionally, during task execution, CPU resources are actively released by calling the task_yield() interface, triggering the scheduler to save the current task context and obtain the next task ID from the request queue for context switching.

[0017] Optionally, when a task needs to wait for a synchronization event, the Wait_Barrier() function is called, which eventually calls the task_yield() interface to trigger task switching; when a task needs to wait for the completion of an external command, the Wait_Cmd_Out() function is called, which notifies the external device through inter-core communication and then calls the task_yield() interface to trigger switching.

[0018] Optionally, after the task is executed, call the task_end() interface to notify the scheduler, and the scheduler clears the task and performs task switching.

[0019] Optionally, the user-mode coroutine scheduler adopts a lock-free design to resolve lock conflicts in high-concurrency scenarios.

[0020] Beneficial effects of the present invention:

[0021] The present invention introduces a state machine model to simplify the state management of coroutines, reduce data structure updates and resource consumption during state switching, and design a user-state coroutine scheduler without the need for operation scheduling, only saving necessary register states, reducing the switching time from microseconds to nanoseconds. The core function of the scheduler is to implement coroutine scheduling using the assembly language of the RSIC-V architecture chip instruction set. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 Schematic diagram of the RSIC-v architecture of the present invention;

[0024] Figure 2 This is a schematic diagram of the user-mode coroutine scheduler of the present invention;

[0025] Figure 3 The software architecture and module deployment diagram of the RSIC-v architecture of the present invention;

[0026] Figure 4 This is the functional scenario activity diagram of the task / coroutine scheduler of the present invention;

[0027] Figure 5 It is the workflow diagram of the present invention. DETAILED DESCRIPTION

[0028] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0029] Example 1

[0030] like Figure 5 As shown, this embodiment provides an efficient collaborative task scheduling method based on an RSIC-v architecture embedded system, comprising the following steps:

[0031] Priority of external trigger conditions: External input requests are divided into two categories: command type requests and event type requests. Event type requests are processed first and trigger corresponding task scheduling;

[0032] Efficient state management: Introducing the state machine model (i.e. Figure 1 The state switching management module simplifies the state management of the coroutine and reduces the data structure update and resource consumption during state switching;

[0033] Lightweight context switching mechanism: Design of user-mode coroutine scheduler (i.e. Figure 1 The core functions of the scheduler are implemented in the assembly language of the RSIC-V architecture chip instruction set and are compatible with the 32-bit / 64-bit high-performance RSIC-V chip series.

[0034] The user-mode coroutine scheduler adopts a lock-free design to resolve lock conflicts in high-concurrency scenarios. The core principle of the lock-free design is to avoid exclusive access to shared resources.

[0035] Lock-Free Programming: Replacing locks with atomic operations (such as CAS, Compare-And-Swap) allows for secure multi-threaded access to shared data. The CAS primitive ensures atomicity by updating a memory location only when the memory location is equal to the expected value (similar to optimistic locking).

[0036] Lock-free data structure transformation: For example, replacing traditional mutually exclusive queues with lock-free queues allows multiple coroutines to join and leave the queue simultaneously without blocking. A typical implementation is a linked list-based Michael-Scott queue, which uses CAS operations to modify node pointers to avoid lock contention.

[0037] Lock-free scheduling process: When scheduling a coroutine, the scheduling state is modified directly through atomic operations (for example, marking the coroutine as runnable) without acquiring a global lock. The scheduler maintains a list of runnable coroutines. When a coroutine is ready, it adds itself to the list through CAS. Other coroutines can read from the list simultaneously.

[0038] like Figure 1 As shown, the RSIC-v architecture embedded system of this embodiment includes a Command queue processing module for command type requests, an Event queue processing module for event type requests, a state switching management module for efficient state management, and a coroutine management and scheduling module for a lightweight context switching mechanism. Each module works collaboratively through a FIFO hybrid priority mechanism.

[0039] The FIFO hybrid priority mechanism is a resource allocation or task processing mechanism that combines the FIFO queue management concept with priority scheduling. While ensuring a certain degree of fairness, it can also perform differentiated processing on tasks or data with different priorities. It is widely used in operating system scheduling, network communication, and data processing.

[0040] FIFO hybrid priority mechanism creates independent queues for different priority tasks (e.g. high priority queue, medium priority queue and low priority queue). Each queue follows FIFO rule internally, while queues are processed in priority order: high priority queue is processed first, then medium priority queue, and finally low priority queue.

[0041] When a high priority task enters the queue, if the currently processing task has lower priority, the high priority task can preempt the processing resource of the low priority task, and after the high priority task is processed, the interrupted low priority task is continued to be processed (the low priority task is still queued in the queue according to FIFO order).

[0042] Different time slices are allocated to different priority tasks: high priority task time slice is long, and low priority task time slice is short. Tasks of the same priority are processed in FIFO order, and if the time slice is used up, the task is queued at the end of the queue to wait for the next round.

[0043] Embodiment 2

[0044] Based on embodiment 1, as shown in Figure 2 , this embodiment describes the state conversion of tasks / coroutines in the design, and the state management of the coroutine of the state machine model at least includes Ready, Running, Suspend and Dead states, and defines the conversion rules between states.

[0045] The state machine model of cooperative scheduling in task scheduling, the core revolves around the conversion logic of tasks between different states (Ready, Running, Suspend, Dead), combined with trigger conditions (Start, Resume, Yield, Exit), which embodies the characteristics of cooperative scheduling tasks actively giving up CPU. The following is the analysis of the key conversion process:

[0046] Initial to Ready (Ready);

[0047] After the task is created, it enters Ready (Ready state), waits to be scheduled and executed, and is the standby state of the task that can be run. Logically, it can be selected for execution, but it has not occupied the CPU.

[0048] Ready→Running (Running);

[0049] Triggered by Start (Start), the scheduler selects a task from the ready queue to make it enter Running (Running state), at which time the task occupies the CPU to execute code logic.

[0050] Running→Suspend (Suspend);

[0051] A task actively gives up the right to use the CPU through the Yield operation and enters the Suspend state. This is common in scenarios where a task needs to wait for resources (such as I / O) and actively relinquishes execution rights to other tasks.

[0052] Suspend→Running

[0053] When the suspend condition is removed (for example, the waiting resource is ready), the task returns to the Running state from the Suspended state through Resume, and reoccupies the CPU to continue execution.

[0054] Running → Dead (terminated);

[0055] After the task is completed (or exits due to an exception), it enters the Dead state through the Exit operation, releases resources, and no longer participates in scheduling.

[0056] Collaborative scheduling relies on tasks actively cooperating and giving up the CPU (yield operation). The scheduler does not force preemption. The advantages are simple implementation and low task switching overhead.

[0057] Example 3

[0058] Based on Example 1, Figure 3 As shown in the figure, the RISC-V architecture embedded system realizes efficient scheduling of storage and computing tasks;

[0059] In the currently designed integrated storage and computing SoC chip system, there are a large number of concurrent computing and storage requests. These storage requests are designed to be grouped into several operator-type tasks. To execute these tasks most efficiently and quickly, task switching and scheduling are performed only when the hardware resources required by these tasks are not available or when they need to wait for the storage operation to complete. The specific task switching and scheduling are as follows:

[0060] RISC-V architecture embedded system initialization phase;

[0061] The number of concurrent tasks supported is predefined (actually, it is set to support 16 task instances simultaneously. Each task instance is an independently runnable code entity with an independent code stack. The task scheduler is responsible for managing and saving the context of tasks / coroutines). The task scheduler is initialized and set to the initial state of Ready. Each created task is assigned a unique task ID number, which cannot be changed throughout the task lifecycle until the task is actively destroyed.

[0062] Parse the input request;

[0063] During system operation, the input processing module identifies the type of external input request (Command or Event) and switches and schedules tasks based on the task ID number in the input request data. This design prioritizes event-type requests over command-type requests to ensure that tasks interrupted by waiting for events are scheduled and completed as quickly as possible. Each task has a unique task ID number, and invalid ID numbers in the input request data are discarded and not processed. All tasks are equal, and task scheduling is based on a combination of input request priority and first-in-first-out (FIFO) principles.

[0064] The task scheduler performs scheduling;

[0065] Jump to the statement where the corresponding task is interrupted and continue executing until the task is completed, or execute the instruction that needs to wait for resources / synchronization signals (implemented by calling the task_yield() interface in the actual code), and actively request to release CPU resources for task scheduling;

[0066] The task scheduler saves the context of the current task and obtains the ID number of the next task to be processed from the request queue, switching the context and jumping the task.

[0067] The task scheduler performs scheduling as follows:

[0068] Hardware resource monitoring module:

[0069] Collect L1 / L2 cache hit rate, memory bandwidth occupancy, and computing unit (ALU / FPU) utilization indicators in real time; establish a resource usage status matrix: ResourceMatrix[Cache,Memory,Compute]

[16] , which records the real-time demand of each task for various resources;

[0070] Resource pre-allocation strategy:

[0071] When a task is created, resource requirements are declared through the task_reserve(resource_mask) interface, and the scheduler predicts resource conflicts based on the ResourceMatrix;

[0072] Pre-allocate 2MB continuous memory blocks for storage-intensive tasks (such as matrix transposition) to reduce page table switching overhead. Dynamic resource reallocation:

[0073] When the memory bandwidth utilization exceeds 80%, the storage requests of non-real-time tasks are automatically merged into batches (up to 8 requests per batch); when the computing unit is detected to be idle, task migration is triggered to dynamically migrate the backlog of computing tasks to the idle core.

[0074] The task scheduling system of a storage-computing integrated SoC will feature more refined resource management capabilities, higher concurrent processing efficiency, and enhanced energy efficiency optimization, making it particularly suitable for storage- and compute-intensive applications such as AI reasoning and big data analysis. Implementation should prioritize optimization based on the specific hardware architecture, for example, implementing an efficient task switching mechanism within the RISC-V architecture.

[0075] Example 4

[0076] Based on Example 3, Figure 4 As shown, task implementation has different requirements and scenarios. The typical implementation of the designed tasks has three basic scenarios:

[0077] During the execution of a task, it needs to wait for a synchronization event. The task can call the Wait_Barrier() function to implement this scenario, and finally call the task_yield() interface API to request the task scheduler to perform task switching);

[0078] During task execution, it is necessary to notify external devices to execute corresponding command operations and wait for the external commands to complete before continuing to run the task. The Wait_Cmd_Out() function can be called to implement this scenario (notifying external devices to execute specified commands is implemented by the inter-core communication function, and then calling the task_yield() interface API to request the task scheduler to perform task switching);

[0079] After all the functions required by the task are completed, you need to call the task_end() interface API to notify the task scheduler that the task execution is completed, clear the task and perform task switching.

[0080] Based on all the above embodiments, the present invention can reduce latency: the context switching time is reduced from 10 μs to 100 ns, and the overall task response time is reduced by at least 30%.

[0081] Improve scheduling efficiency: Through dynamic priority adjustment and intelligent scheduling strategies, the scheduler's computational overhead when selecting coroutines to execute is reduced, significantly improving scheduling efficiency.

[0082] Simplified scheduler state management: The introduction of a state machine model reduces data structure update operations during state switching and reduces management complexity.

[0083] Resource contention optimization: The lock-free design solves the problem of lock conflicts and is suitable for high-concurrency scenarios.

[0084] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope of the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. An efficient collaborative task scheduling method based on RSIC-v architecture embedded system, characterized in that: The steps include: Priority of external trigger conditions: The external input requests of the RSIC-v architecture embedded system are divided into two categories: command type requests and event type requests. Event type requests are processed first and trigger corresponding task scheduling; Efficient state management: Introducing a state machine model to simplify coroutine state management, thereby reducing data structure updates and resource consumption during state switching; Lightweight context switching mechanism: A user-mode coroutine scheduler is designed that does not require operating system scheduling and only saves the necessary register states of PC and SP. The core functions of the scheduler are implemented using the assembly language of the RSIC-V architecture chip instruction set.

2. The efficient collaborative task scheduling method based on the RSIC-v architecture embedded system according to claim 1, characterized in that: When external requests are input and parsed, requests with illegal task IDs are discarded, and tasks are scheduled based on the FIFO mixed priority mechanism, with Event requests taking precedence over Command requests.

3. The efficient collaborative task scheduling method based on the RSIC-v architecture embedded system according to any one of claims 1 or 2, characterized in that: The RSIC-v architecture embedded system includes a command queue processing module, an event queue processing module, a state switching management module, and a coroutine management and scheduling module, and each module works collaboratively through a FIFO hybrid priority mechanism.

4. The efficient collaborative task scheduling method based on the RSIC-v architecture embedded system according to claim 1, characterized in that: The state management of the coroutine of the state machine model includes at least the states of Ready, Running, Suspend and Dead, and defines the transition rules between each state.

5. The efficient collaborative task scheduling method based on RSIC-v architecture embedded system according to claim 1, characterized in that: The context switching time of the user-mode coroutine scheduler is reduced from microseconds to nanoseconds, and is compatible with 32-bit / 64-bit RISC-V chip series.

6. The efficient collaborative task scheduling method based on the RSIC-v architecture embedded system according to claim 1, characterized in that: During the initialization phase of the RSIC-v architecture embedded system, the number of concurrent tasks supported is predefined, a unique task ID that remains unchanged during its life cycle is assigned to each task, and the initial state of the task is set to Ready.

7. The efficient collaborative task scheduling method based on RSIC-v architecture embedded system according to claim 6, characterized in that: During task execution, CPU resources are actively released by calling the task_yield() interface, triggering the scheduler to save the current task context and obtain the next task ID from the request queue for context switching.

8. The efficient collaborative task scheduling method based on RSIC-v architecture embedded system according to claim 7, characterized in that: When a task needs to wait for a synchronization event, the Wait_Barrier() function is called, which eventually calls the task_yield() interface to trigger task switching. When a task needs to wait for an external command to be executed, the Wait_Cmd_Out() function is called, which notifies the external device through inter-core communication and then calls the task_yield() interface to trigger switching.

9. The efficient collaborative task scheduling method based on RSIC-v architecture embedded system according to claim 8, characterized in that: After the task is executed, the task_end() interface is called to notify the scheduler, and the scheduler clears the task and performs task switching.

10. The efficient collaborative task scheduling method based on RSIC-v architecture embedded system according to claim 1, characterized in that: The user-mode coroutine scheduler adopts a lock-free design to solve the lock conflict problem in high-concurrency scenarios.

Images