Bpf-based on-chip heterogeneous multiprocessor system task scheduling system and method

Abstract

A task scheduling system and method of a BPF-based on-chip heterogeneous multiprocessor system, comprising: a scheduling module and a sending module located at a general operating system Linux end, a receiving module located at a real-time operating system end, a BPF bytecode analysis and execution module and a calculation module, the application uses BPF virtual machine technology, uses BPF bytecode as the transmission carrier between the general operating system Linux and the real-time operating system of the on-chip heterogeneous multiprocessor, and schedules the to-be-processed application program in the part of the general operating system Linux to the real-time operating system in real time, and executes in the BPF instruction analysis and BPF virtual machine. The application can achieve certain load balancing and maximize the use of on-chip heterogeneous multiprocessor resources of the system without increasing the hardware design cost.

Description

Technical Field

[0001] This invention relates to a technology in the field of computer processing, specifically an on-chip heterogeneous multiprocessor system task scheduling system and method based on Berkeley Packet Filter (BPF). Background Technology

[0002] On-chip homogeneous multiprocessors typically integrate multiple general-purpose processors (CPUs) with the same architecture. However, the newly introduced on-chip heterogeneous multiprocessors based on Arm Cortex technology integrate both Arm Cortex-A and Cortex-M general-purpose processors, offering unique advantages in improving system throughput and execution efficiency. Existing hardware and software architectures based on on-chip heterogeneous multiprocessors struggle to manage processor resources under two operating systems simultaneously, and general scheduling algorithms often focus on a single system and cannot coordinate remote processor resources. While the open-source OpenAsymmetric MultiProcessing framework (OpenAMP) and Remote Processor Messaging (RPMsg) provide support for inter-core communication in on-chip heterogeneous multiprocessors, in real-world applications, the two operating systems run independently, and their resources are isolated, making collaborative management impossible. Secondly, existing on-chip heterogeneous multiprocessor scheduling methods mostly focus on how to program computational tasks onto different GPUs or DSPs to reduce the load on the general-purpose processor. However, this often requires additional hardware resources and design costs, as well as requiring programmers to program according to the specifications of the GPU or DSP. Porting the code to other system platforms also presents certain difficulties. Furthermore, there are significant differences between the two operating systems, including instruction sets, compilation systems, and middleware software, which also brings difficulties to the porting of scheduling algorithms. Due to these limitations, the scheduling of the two systems cannot be synchronized. This may result in a situation where, at a certain moment, the general-purpose operating system (such as Linux) is overloaded and unable to process user requests in a timely manner, while the real-time operating system remains idle or under low load, doing nothing. Consequently, the processor, as the most valuable resource, is not coordinated and fully utilized.

[0003] In summary, these existing on-chip homogeneous multiprocessor or on-chip heterogeneous multiprocessor system solutions have some limitations in terms of processor resource utilization, design cost, or operating system, and cannot fully utilize the Cortex-A and Cortex-M processor resources of on-chip heterogeneous multiprocessor systems based on ARM Cortex technology. Summary of the Invention

[0004] This invention addresses the limitations of existing Cortex-M processors that do not support Linux and require pre-deploying computing tasks to the DSP according to DSP programming specifications, resulting in additional development workload. It proposes a task scheduling system and method for on-chip heterogeneous multiprocessor systems based on BPF, which achieves a certain degree of load balancing and maximizes the utilization of the system's on-chip heterogeneous multiprocessor resources without increasing hardware design costs.

[0005] This invention is achieved through the following technical solution:

[0006] This invention relates to a task scheduling system for an on-chip heterogeneous multiprocessor operating system, comprising: a scheduling module and a sending module located on the general-purpose operating system (Linux), a receiving module located on the real-time operating system (RTOS), a BPF bytecode parsing and execution module, and a computing module, wherein: the scheduling module makes scheduling decisions for computing tasks based on a predefined scheduling policy and system running status information, scheduling the computing tasks to the ROS for execution; the sending module sends BPF bytecode in ELF file format to the ROS according to the instructions of the scheduling module, and waits to receive the execution result returned by the ROS; the receiving module, used to listen for BPF requests, receives the BPF bytecode file from the Linux side according to the inter-core communication mechanism, and after receiving it, sends it to the BPF bytecode parsing and execution module, waits for the computing result, and sends it back to the Linux side; the BPF bytecode parsing and execution module parses and executes the BPF bytecode based on the BPF file received by the receiving module, calls the computing module to process the computing task, and returns the execution result to the receiving module; the computing module executes and processes the computing task according to the extended BPF helper function list information, and returns the computing result to the BPF bytecode parsing and execution module.

[0007] The scheduling module is responsible for loading the executable file containing the BPF bytecode of the computing task into memory, making scheduling decisions based on scheduling conditions, and deploying the BPF file to the real-time operating system for processing through the sending module when the scheduling conditions are met; otherwise, the scheduling module will not remotely deploy the task, and the computing task will run normally on the Linux side according to the original code logic.

[0008] The scheduling conditions include: when the Linux system is under high load, a scheduling request can be executed to reduce the CPU usage on the Linux side; when the Linux system is idle or in a normal state, the application can actively initiate a scheduling request to the scheduling module to reserve more CPU bandwidth for Linux or reduce power consumption; the scheduling request does not affect the stability and reliability of the real-time operating system itself; when a high-priority real-time task appears in the real-time operating system, the currently scheduled computing task will be paused and wait for rescheduling.

[0009] The scheduling conditions described herein are formulated and expanded based on actual application scenarios and user needs.

[0010] The deployment refers to the scheduling module deciding whether to schedule computational tasks to run on a remote Cortex-M processor based on predetermined configuration parameters (e.g., whether to prioritize deploying tasks to a remote processor) or system status (e.g., the Linux system has reached or exceeded 80% processor utilization). When the scheduling conditions are met, the scheduling module schedules the computational tasks to run on the real-time operating system (RTOS) where the remote Cortex-M processor resides. The executable file (ELF format) containing BPF bytecode is transmitted by the sending module to the ROS for further processing. Simultaneously, the Linux system releases processor resources and waits for processing results, allowing the Cortex-A processor on the Linux side to spend less time and have more bandwidth to handle other tasks. Meanwhile, the Cortex-M processor on the ROS side is fully utilized to handle these deployed tasks, thus making more efficient use of the entire system's processor resources.

[0011] The receiving module listens for BPF requests on the virtual serial port device through the inter-core communication mechanism between Cortex-A and Cortex-M, using the API interface provided by OpenAMP, and packages the data and sends it to the BPF bytecode parsing and execution module for subsequent processing.

[0012] The BPF bytecode parsing and execution module, based on lightweight BPF virtual machine technology, parses and executes BPF bytecode on the real-time operating system side. That is, it verifies and parses the BPF bytecode sent from the host processor, executes BPF instructions, and can perform more computing tasks through the Extended Computing Module (ERHF) to achieve an effect similar to Remote Procedure Call (RPC). This module includes: a BPF bytecode verifier, a BPF bytecode parser, and a BPF virtual machine.

[0013] The BPF virtual machine includes a 512KB stack and 11 registers. Function calls use only 5 parameters (registers r1-r5), register r0 stores the function's return value, and the PC register points to the currently executing BPF bytecode. Upon receiving BPF bytecode data from the BPF request listener, the BPF bytecode verifier checks the integrity of the executable containing the BPF bytecode. If the check is successful, the BPF bytecode parser will parse and execute each BPF bytecode sequentially. If the check fails or a parsing error occurs, an error code will be returned to the Linux side, indicating that the scheduling execution has failed and corrective action is required, or the original Linux scheduler needs to be executed. During instruction parsing, if the current BPF bytecode is a regular BPF instruction, such as a memory access instruction, it will be executed normally. After execution, the next instruction will be parsed and executed. If the current BPF bytecode is an E-RHF instruction, it will enter the computation module (ERHF), run the corresponding custom processing function, and complete the computation task. Once the computation module completes execution, it will return from E-RHF to the BPF bytecode where the jump occurred and continue execution. If the current BPF bytecode is a termination instruction, it will exit the execution module and return the computation result to the Linux side.

[0014] The aforementioned computing module, based on Extended Remote Helper Functions (E-RHF), extends Linux BPF helper functions from the originally predefined Linux kernel helper functions to any user-defined function, thereby greatly enriching the supported functional range and expanding the interfaces of various functions. This allows E-RHF to truly function as a computing module on the real-time operating system side. E-RHF is defined and implemented on the real-time operating system side, porting or implementing the relatively complex computational code, such as cumulative summation or matrix multiplication in C code or functions, to the real-time operating system side, and then calling these remote BPF helper functions within the BPF bytecode. This is equivalent to establishing a mapping from Linux to the real-time operating system side for remote function calls, not only overcoming the limitations of the BPF instruction set and giving BPF extended functions richer function processing capabilities, but also further improving the execution efficiency of these computational codes.

[0015] This invention relates to a task scheduling method for an on-chip heterogeneous multiprocessor system based on the above-mentioned system. It uses BPF virtual machine technology and BPF bytecode as the transmission carrier between the general-purpose operating system Linux and the real-time operating system of the on-chip heterogeneous multiprocessor. The method schedules some computing tasks of the application in the general-purpose operating system Linux to the real-time operating system and executes them in its BPF instruction parsing and BPF virtual machine in real time.

[0016] The BPF virtual machine technology refers to: pre-analyzing the type of the application to be processed, identifying computational tasks or functions suitable for scheduling to the real-time operating system and capable of being compiled into BPF bytecode, pre-processing and compiling them into BPF bytecode, generating an executable file containing BPF bytecode; then adding the calling logic for the BPF bytecode and defining the scheduling trigger conditions for the scheduling module in the application to be processed; finally, in the execution phase, the scheduling module schedules the executable file containing BPF bytecode to the real-time operating system for execution, and the BPF bytecode parsing and execution module and the computation module on the real-time operating system side perform the parsing and execution of BPF instructions and the computation tasks, respectively.

[0017] The aforementioned analysis and identification refers to selecting some non-human-computer interaction or time-insensitive background service programs in the Linux system as programs to be processed, and further selecting a portion of these programs that are relatively simple in logic but consume a lot of processor power and are purely computational tasks as targets for analysis and processing. Such computational tasks or functions include, but are not limited to, cumulative summation, matrix multiplication, etc.

[0018] The preprocessing mentioned refers to: generating BPF bytecode files, porting or implementing computational task functions in the E-RHF of the real-time operating system, and adding scheduling request calls to existing Linux applications, specifically including:

[0019] ① The computation-related code is segmented and encapsulated, compiled into BPF bytecode using LLVM / Clang tools, and an executable file (executable and linkable format, ELF) is generated.

[0020] ② Port or implement relatively complex computational task functions in the real-time operating system and add them to the E-RHF module. Call these remote BPF helper functions in the BPF bytecode to establish a one-to-one remote function call.

[0021] ③ Add a call to the scheduling request in the original code on the Linux side and generate a unique request number to distinguish the request.

[0022] The computational tasks or functions mentioned include, but are not limited to, summation, matrix multiplication, etc.

[0023] The executable file introduces extended remote helper functions (E-RHF), which expands the supported functions from the original predefined Linux kernel helper functions to arbitrary user-defined functions. The compiled computing tasks or functions are ported or implemented on the real-time operating system side, and the corresponding remote BPF functions are called in the BPF bytecode, thus establishing a mapping relationship for remote function calls from the general operating system to the real-time operating system.

[0024] The addition is consistent with the original application's operating logic and can schedule BPF bytecode through the scheduling module when the corresponding scheduling trigger conditions are met.

[0025] The scheduling triggering conditions include, but are not limited to, configuration of environment variables and detection of system processor utilization.

[0026] The real-time scheduling refers to the following: when a computing task meets the scheduling trigger conditions, its corresponding executable file is sent to the real-time operating system via the sending module and processed by the real-time operating system, while the general-purpose operating system Linux releases processor resources and waits for the processing result; when the computing task does not meet the scheduling trigger conditions, it runs normally on the general-purpose operating system Linux according to the original logic.

[0027] The real-time operating system processing refers to the following: after the receiving module receives the executable file, it outputs the BPF bytecode to the BPF bytecode parsing and execution module. The BPF bytecode parsing and execution module checks the integrity of the executable file containing the BPF bytecode and then parses and executes each BPF bytecode in sequence.

[0028] The parsing refers to: interpreting the BPF bytecode into corresponding executable statements based on the BPF bytecode instruction set and executing them. The Extended Remote Helper Function (E-RHF) instruction is used by the computation module to run the corresponding custom processing function, complete the computation task, and return to the BPF bytecode at the time of the jump after execution.

[0029] Technical effect

[0030] This invention uses BPF bytecode as the transmission medium between Cortex-A and Cortex-M processors. Under the scheduling module, the application program schedules some computational tasks to the Cortex-M processor for execution, thereby achieving parallelization of computational tasks on both Cortex-A and Cortex-M processors. Furthermore, the E-RHF module of the real-time operating system can efficiently complete the computational tasks. Compared with existing technologies, this invention utilizes existing hardware resources, requires minimal modification to the original application program, and does not alter the original program execution logic when scheduling conditions are not triggered. Computational tasks or function code from the general-purpose Linux operating system can be easily ported to the real-time operating system, and the existing scheduling algorithms of the real-time operating system can be fully utilized. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the system of the present invention;

[0032] Figure 2 This is a flowchart of the present invention;

[0033] Figure 3This is a schematic diagram of the source file preprocessing process in an embodiment;

[0034] Figure 4 This is a schematic diagram illustrating the implementation and execution of the ERHF instruction in an example.

[0035] Figure 5 This is a schematic diagram comparing the performance improvement of the example under single-core conditions;

[0036] Figure 6 This is a schematic diagram illustrating the performance improvement of the system under high load in an example embodiment. Detailed Implementation

[0037] like Figure 1 As shown in this embodiment, a task scheduling system for an on-chip heterogeneous multiprocessor system based on BPF is included. It comprises a scheduling module and a sending module located in the general-purpose operating system (Linux) portion, and a BPF bytecode parsing and execution module, a computation module, and a receiving module located in the real-time operating system portion. In this embodiment, the Cortex-A processor acts as the local processor, while the Cortex-M processor acts as the remote processor. Based on various basic software and hardware components, corresponding virtual devices, such as virtual serial port devices, are accessed on both the Linux and real-time operating system sides. Message passing and content sharing between heterogeneous processors are achieved through the remote processor message passing protocol.

[0038] like Figure 2 As shown, this embodiment illustrates the on-chip heterogeneous multiprocessor system task scheduling method based on the aforementioned system. In the offline phase, the method first... Figure 1 The example application is analyzed, preprocessed, and compiled into BPF bytecode. The example application is then scheduled by the scheduling module, and the sending module sends the BPF bytecode to the real-time operating system (RTOS) via a virtual device and remote processor messaging protocol. The ROS then processes the bytecode, releasing processor resources and awaiting the results. On the ROS side, when the receiving module receives the BPF bytecode from Linux, it is parsed by the BPF instruction parsing and execution module, and the computation module performs the relevant computational tasks. After processing, the results are returned to the Linux side. The specific steps include:

[0039] Step 1) Analyze the application type: The BPF virtual machine's instruction set currently supports basic arithmetic, memory access, and jump instructions. Combining the capabilities of the BPF virtual machine and the real-time operating system, we will focus on a subset of relatively simple but processor-intensive pure computational tasks as the target for analysis and processing. Considering the inevitable latency introduced by redeploying these tasks to the real-time operating system, including inter-core transfers, instruction parsing and execution, remote call processing, and the performance differences between Cortex-A and Cortex-M processors, this method is more suitable for non-human-computer interaction tasks or certain background service tasks that are not sensitive to runtime.

[0040] Step 2) Preprocess the application source files and generate BPF bytecode: Following the analysis and preprocessing of program tasks in Step 1), computation-related tasks are identified, such as C language code or functions for summation and matrix multiplication. This computation-related code is then re-segmented and encapsulated. The code requiring scheduling and redeployment is compiled into BPF bytecode using LLVM / Clang tools, ultimately generating an executable file (Executable and Linkable Format, ELF). Furthermore, calls to the BPF bytecode and corresponding trigger conditions for the scheduling module are added to the existing code's call flow (e.g., through environment variable configuration or monitoring system processor utilization). This ensures that these modifications conform to the original program execution logic and that the scheduling module can schedule the BPF bytecode to the real-time operating system for execution when the corresponding conditions are met. The entire process is as follows: Figure 3 As shown.

[0041] Step 3) Define and use the extended remote helper function E-RHF: Based on the concept of BPF helper functions, the extended remote helper function E-RHF is introduced as a computation module. It extends the original predefined Linux kernel helper functions to arbitrary user-defined functions. The extended remote helper function E-RHF takes the computational tasks identified in Step 2), such as cumulative summation, matrix multiplication, and other C language code or functions, and... Figure 4 As shown, these relatively complex computational codes are ported or implemented on the real-time operating system side, and these remote BPF functions are called in the BPF code.

[0042] Step 4) Scheduling and processing of computing tasks on the Linux side. After the offline stage of encapsulating and compiling the computing tasks, when the example program runs, the scheduling module determines whether to deploy the computing tasks to the remote Cortex-M processor according to the method based on configuration parameters (such as whether to prioritize deployment to the remote processor) or system status (such as the processor utilization rate of the Linux system reaching or exceeding 80%). When the above scheduling conditions are not met, the example program will run normally on the Linux side according to the original code logic, such as... Figure 2 As shown.

[0043] Step 5) After the scheduling module redeploys the computing task in Step 4), the sending module sends the BPF bytecode file to the real-time operating system through the virtual device and remote processor messaging protocol. The real-time operating system then processes the file, while the Linux side releases processor resources and waits for the processing result.

[0044] Step 6) When the BPF request listener on the real-time operating system side receives the BPF bytecode data from the general operating system, it sends it to the BPF bytecode parsing and execution module (BPF virtual machine).

[0045] Step 7) The BPF virtual machine on the real-time operating system side checks whether the BPF bytecode in ELF format is correct. If the check is successful, each BPF bytecode is parsed sequentially: for ordinary BPF instructions, they are executed directly, and then the next instruction is parsed; for extended remote helper function (E-RHF) instructions, the computation module E-RHF will be entered to run the corresponding computation task function (i.e., ported or reimplemented C language code or functions such as summation and matrix multiplication), thereby achieving an effect similar to a remote system call, such as... Figure 4 As shown. After the E-RHF computation task function completes, it returns to the BPF bytecode at the time of the jump and continues parsing the next instruction. When an end instruction is encountered, it exits the BPF virtual machine and returns the previously obtained computation results to the Linux side via the virtual device and remote processor message passing protocol.

[0046] Through practical experiments, this invention was deployed on an on-chip heterogeneous multiprocessor embedded platform, and the performance data of some typical computing programs were measured. The performance differences between the scheduling methods of ordinary Linux systems and the scheduling methods of this invention were compared in these programs. The embodiment uses matrix calculation and Cyclic Redundancy Check (CRC) calculation as example programs. Using the above implementation methods, the example program can determine whether the test cases run on a Linux system or a real-time operating system based on configuration parameters or system load status, and the key performance indicator of iterations per second is compared under various test cases. The embodiment selects the STM32MP157 as the hardware reference platform, employing a dual Arm Cortex-A7 processor (800 MHz operating frequency) and a single Cortex-M4 processor (209 MHz operating frequency) architecture. The software operating systems are Linux (Yocto+Kernel 5.4.31) running on the Cortex-A7 processor and TencentOS tiny running on the Cortex-M4 processor.

[0047] Single-core performance comparison: CRC test case 1 runs a single CRC test program under a Linux system, records the corresponding running time, and converts it into iterations per second. CRC test case 1 uses existing Linux scheduling technology and does not utilize the full computing power of the Linux system's processor; it runs only on a single Cortex-A7 when the system is idle. In contrast, CRC test case 2 will follow the scheduling method of this invention, using computational parallelization to run a CRC test program on both the Linux system and the real-time operating system, thus utilizing the computing power of both a single Cortex-A7 and a single Cortex-M4 simultaneously.

[0048] By recording and comparing the results of the two sets of test cases at different iteration counts (Table 1), the CRC test case 2 of this invention improves the number of iterations per second by approximately 24% compared to the conventional CRC test case 1. Figure 5 As shown.

[0049] Table 1 Comparison of CRC test case results (single core)

[0050]

[0051] The results of matrix calculation test cases 1 and 2 (as shown in Table 2) also yielded similar conclusions. Test case 1 ran a single matrix test program under a Linux system. Test case 2, following the method of this invention, ran a matrix test program simultaneously on both a Linux system and a real-time operating system. As the number of test loops increased, the impact of inter-core transfer overhead gradually decreased, and its iterations per second, with the help of this invention, increased by 20% to 25% compared to test case 1. Figure 5 As shown.

[0052] Table 2 Comparison of Matrix Calculation Test Case Results (Single Core)

[0053]

[0054] Overall performance comparison under high load: Improving the overall computing performance of the system under high load is also one of the main application scenarios of this invention. To evaluate the processor integer computing performance of a multiprocessor system under high load, it is necessary to run two or more test programs to put the system under high load, record the corresponding running time, and compare the number of iterations per second under different test cases.

[0055] Matrix test case 3 involves running two matrix test programs under a Linux system, recording the corresponding runtime, and converting it into iterations per second. Under existing Linux scheduling technology, this test case would run simultaneously on two Cortex-A7 processors, thus putting the Linux system under high load. Of course, in this scenario, the Cortex-M4 is not involved in computation and remains idle. Matrix test case 4, following the method of this invention, runs two matrix test programs under a Linux system and simultaneously schedules one of them to run on the real-time operating system, thus utilizing the computing power of both Cortex-A7 and a single Cortex-M4. By recording and comparing the results of the two test cases at different iteration counts (Table 3), matrix test case 4 using this invention improves the iterations per second by approximately 12% compared to the conventional matrix test case 3. Figure 6 As shown, this invention provides approximately 12% additional integer computing power to the entire Linux system. Furthermore, as the number of test loops increases, the impact of inter-core transfer overhead and program startup time gradually decreases, and the computation results gradually stabilize.

[0056] Similar conclusions were reached in CRC test cases 3 and 4, such as... Figure 6 As shown. In summary, in the above matrix and CRC test cases, this invention significantly improves the computational performance of a single core (approximately 24%) and the overall system (approximately 12%) compared to ordinary Linux scheduling methods through computational parallelization.

[0057] Table 3 Comparison of Matrix Calculation Test Case Results (High Load)

[0058]

[0059]

[0060] In summary, the experimental results of the embodiments show that the present invention can improve the computing throughput and system performance of the entire platform through computational parallelization, providing 24% of the computing power of a single Cortex-A7 processor for a single computing task, and reducing the processor utilization of the general-purpose operating system Linux by about 12% when the system is under high load. That is, while making full use of processor resources, it provides an additional 12% computing power for the general-purpose operating system Linux.

[0061] Compared with existing technologies, this invention utilizes the characteristics of the BPF virtual machine and BPF bytecode, as well as the portability of extended remote BPF function calls, to overcome the problems and limitations of existing technical solutions. Its advantage lies in fully utilizing the Cortex-A and Cortex-M processors of the on-chip heterogeneous multiprocessor system. Compared with existing Linux scheduling methods, it optimizes processor resource utilization and significantly reduces the processor load of the Linux system on the Cortex-A processor. By parallelizing computation, it improves the overall platform's computational throughput and system performance. The resulting performance improvement can better serve embedded application systems.

[0062] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A task scheduling system for an on-chip heterogeneous multiprocessor system based on BPF, characterized in that, include: The system comprises a scheduling module and a sending module located on the general-purpose operating system (Linux), a receiving module, a BPF bytecode parsing and execution module, and a computation module located on the real-time operating system (RTOS). Specifically: the scheduling module makes scheduling decisions for computation tasks based on predefined scheduling policies and system runtime information, scheduling these tasks to the ROS for execution; the sending module sends BPF bytecode in ELF file format to the ROS according to instructions from the scheduling module and waits for the execution result returned by the ROS; the receiving module, used to listen for BPF requests, receives the BPF bytecode file from the Linux side according to the inter-core communication mechanism, sends it to the BPF bytecode parsing and execution module, waits for the computation result, and sends it back to the Linux side; the BPF bytecode parsing and execution module parses and executes the BPF bytecode received by the receiving module, calls the computation module to process the computation task, and returns the execution result to the receiving module; the computation module executes and processes the computation task according to the extended BPF helper function list and returns the computation result to the BPF bytecode parsing and execution module.

2. The on-chip heterogeneous multiprocessor system task scheduling system based on BPF according to claim 1, characterized in that, The scheduling module loads the executable file containing the BPF bytecode of the computing task into memory, makes scheduling decisions based on scheduling conditions, and deploys the BPF file to the real-time operating system for processing through the sending module when the scheduling conditions are met. Otherwise, the scheduling module will not perform remote deployment of tasks, and the computing tasks will run normally on the Linux side according to the original code logic; The scheduling conditions include: executing scheduling requests when the Linux system is under high load, thereby reducing CPU usage on the Linux side; When the Linux system is idle or in a normal state, the application actively sends a scheduling request to the scheduling module, thereby reserving more CPU bandwidth for Linux or reducing power consumption. The scheduling request does not affect the stability and reliability of the real-time operating system itself. When a high-priority real-time task appears in the real-time operating system, the currently scheduled computing task will be paused and wait for rescheduling.

3. The on-chip heterogeneous multiprocessor system task scheduling system based on BPF according to claim 2, characterized in that, The deployment refers to the following: the scheduling module will decide whether to schedule the computing task to run on the remote Cortex-M processor based on the predetermined configuration parameters or system status; when the scheduling conditions are met, the scheduling module will schedule the computing task to run on the real-time operating system where the remote Cortex-M processor is located. The executable file containing BPF bytecode is transmitted by the sending module to the real-time operating system for subsequent processing. At the same time, the Linux system releases processor resources and waits for the processing results.

4. The on-chip heterogeneous multiprocessor system task scheduling system based on BPF according to claim 1, characterized in that, The receiving module listens for BPF requests on the virtual serial port device through the inter-core communication mechanism between Cortex-A and Cortex-M, using the API interface provided by OpenAMP, and packages the data and sends it to the BPF bytecode parsing and execution module for subsequent processing.

5. The on-chip heterogeneous multiprocessor system task scheduling system based on BPF according to claim 1, characterized in that, The BPF bytecode parsing and execution module is based on lightweight BPF virtual machine technology to parse and execute BPF bytecode on the real-time operating system side. That is, it verifies and parses the BPF bytecode sent from the host processor, executes BPF instructions, and performs more computing tasks through the extended computing module. The module includes: BPF bytecode verifier, BPF bytecode parser and BPF virtual machine. Upon receiving BPF bytecode data from the BPF request listener, the BPF bytecode verifier checks the integrity of the executable file containing the BPF bytecode. If the check is successful, the BPF bytecode parser will parse and execute each BPF bytecode in sequence; otherwise, an error code will be returned to the Linux side, indicating that the scheduling execution has failed and corrective measures are needed or the original Linux scheduling needs to be executed. During instruction parsing, if the current BPF bytecode is a normal BPF instruction, it will be executed normally. After execution, the next instruction will be parsed and executed. If the current BPF bytecode is an E-RHF instruction, the corresponding custom processing function will be run through the computation module (ERHF) until the computation task is completed. After the computation module finishes execution, the instruction will return from the E-RHF to the BPF bytecode where the jump occurred and continue execution. If the current BPF bytecode is a termination instruction, the execution module will exit and the computation result will be returned to the Linux side.

6. The on-chip heterogeneous multiprocessor system task scheduling system based on BPF according to claim 5, characterized in that, The BPF virtual machine includes a 512KB stack and 11 registers, of which: the second to sixth registers r1-r5 are used for the five parameters used in the function call, the first register r0 is used to store the function return value, and the PC register points to the currently executing BPF bytecode.

7. The on-chip heterogeneous multiprocessor system task scheduling system based on BPF according to claim 1, characterized in that, The aforementioned computing module extends the BPF helper functions under Linux from the original predefined Linux kernel helper functions to any user-defined function based on extended remote helper functions. It defines and implements E-RHF on the real-time operating system side, ports or implements the computing task code on the real-time operating system side, and calls the remote BPF helper functions in the BPF bytecode.

8. A task scheduling method for an on-chip heterogeneous multiprocessor system based on the task scheduling system according to any one of claims 1-7, characterized in that, Using BPF virtual machine technology, BPF bytecode is used as the transmission medium between the general-purpose operating system Linux and the real-time operating system on the on-chip heterogeneous multiprocessor. This allows some computational tasks of the application on the general-purpose operating system Linux to be scheduled to the real-time operating system in real time and executed in its BPF instruction parsing and BPF virtual machine. The BPF virtual machine technology refers to: pre-analyzing the type of the application to be processed, identifying computing tasks or functions suitable for scheduling to a real-time operating system and capable of being compiled into BPF bytecode, pre-processing and compiling them into BPF bytecode, generating an executable file containing BPF bytecode; then adding the calling logic of the BPF bytecode and defining the scheduling trigger conditions of the scheduling module in the application to be processed; Finally, during the execution phase, the scheduling module schedules the executable file containing BPF bytecode to the real-time operating system for execution. The BPF bytecode parsing and execution module and the calculation module on the real-time operating system side perform the parsing and execution of BPF instructions and the calculation tasks, respectively.

9. The task scheduling method for an on-chip heterogeneous multiprocessor system according to claim 8, characterized in that, The preprocessing mentioned refers to: generating BPF bytecode files, porting or implementing computational task functions in the E-RHF of the real-time operating system, and adding scheduling request calls to existing Linux applications, specifically including: ① The computation-related code is segmented and encapsulated, compiled into BPF bytecode using LLVM / Clang tools, and an executable file is generated; ② Port or implement relatively complex computational task functions in the real-time operating system and add them to the E-RHF module. Call these remote BPF helper functions in the BPF bytecode to establish a one-to-one remote function call. ③ Add a call to the scheduling request in the original code on the Linux side and generate a unique request number to distinguish the request.

10. The on-chip heterogeneous multiprocessor system task scheduling method according to claim 8, characterized in that, The executable file introduces extended remote helper functions (E-RHF), which expands the supported functions from the original predefined Linux kernel helper functions to arbitrary user-defined functions. The compiled computing tasks or functions are ported or implemented on the real-time operating system side, and the corresponding remote BPF functions are called in the BPF bytecode, thus establishing a mapping relationship for remote function calls from the general operating system to the real-time operating system.

Images