Real-time task arbitration method of heterogeneous OS cluster and related equipment

Abstract

The invention discloses a real-time task arbitration method of a heterogeneous OS cluster and related equipment, and relates to the technical field of computers, the method comprises the following steps: collecting a resource request signal, task priority data, a global timestamp and a resource identifier of a multi-core processor through a hardware interface; performing standardized mapping on task priority data, and dynamically calculating an effective priority based on waiting time; aiming at concurrent resource request signals of resources of the same resource identifier, arranging the resource request signals in a descending order according to effective priorities through a hardware sorting network, and performing timestamp defeat on the highest priority group by adopting a global timestamp; sending a resource authorization signal to the winning core and configuring a bus route; and dynamically adjusting a priority weighting parameter according to the historical arbitration data. According to the method, various data are collected through a hardware interface, then calculation is effective, then the global timestamp is adopted to carry out decision arbitration, and a priority hardware-assisted cross-OS real-time arbitration scheme can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a real-time task arbitration method for a heterogeneous OS cluster and related equipment. BACKGROUND

[0002] With the development of heterogeneous computing, AMP / SMP hybrid architecture is widely used in automatic driving, industrial control and other fields. The traditional scheme has three defects: 1. High software arbitration delay: the Linux kernel scheduler delay is usually > 100us, which cannot meet the hard real-time requirements of RTOS (such as < 10us required by automotive ECU); 2. Priority incompatibility: the fixed priority of RTOS cannot be directly compared with the Linux CFS scheduler, resulting in improper resource allocation; 3. Starvation phenomenon frequently occurs: under high load, low priority tasks are blocked for a long time, such as the reversal rate of 15% in the scheme disclosed in CN202410123456.7.

[0003] Existing hardware arbiters (such as ARM CCI bus) only support physical address conflict detection and lack task-level priority awareness capability. SUMMARY

[0004] The main purpose of the embodiments of the present application is to provide a real-time task arbitration method for a heterogeneous OS cluster and related equipment to improve arbitration efficiency.

[0005] To achieve the above purpose, one aspect of an embodiment of the present application provides a real-time task arbitration method for a heterogeneous OS cluster, which comprises the following steps: Collecting resource request signals, task priority data, global timestamps and resource identifiers of a multi-core processor through a hardware interface; Standardizing mapping of the task priority data and dynamically calculating effective priority based on waiting time; For concurrent resource request signals of the same resource identifier, arranging the resource request signals in descending order of the effective priority through a hardware sorting network, and using the global timestamp for timestamp decision for the highest priority group; Sending a resource authorization signal to the winning core and configuring bus routing; Dynamically adjusting priority weighting parameters according to historical arbitration data.

[0006] In some embodiments, the collecting of resource request signals, task priority data, global timestamps and resource identifiers of a multi-core processor through a hardware interface comprises the following steps: Collecting RTOS task priority through a coprocessor; Injecting Linux task priority by modifying the kernel spinlock mechanism; The resource identifier is encoded by a shared memory block or a hardware accelerator.

[0007] In some embodiments, the standardizing mapping of the task priority data comprises the following steps: standardizing mapping of the task priority data according to a priority standardization calculation formula; The priority standardization calculation formula is: NORM_PRIO = (RAW_PRIO - MIN_SRC) × (MAX_TARGET - MIN_TARGET) / (MAX_SRC - MIN_SRC) + MIN_TARGET; wherein MIN_SRC / MAX_SRC is a pre-configured source OS priority range, and MIN_TARGET / MAX_TARGET is a standardized target range.

[0008] In some embodiments, the dynamically calculating effective priority based on latency comprises the following steps: calculating effective priority according to an effective priority calculation formula; The effective priority calculation formula is: EFFECTIVE_PRIO = NORM_PRIO + α × (CURRENT_TIME - EQ_TIMESTAMP); wherein the attenuation factor α can be configured by hardware, and the default value is 0.05 / μs.

[0009] In some embodiments, when the highest priority group adopts the global timestamp for timestamp decision, the method further comprises performing an anti-starvation mechanism, which comprises the following steps: monitoring a maximum waiting time MAX_WAIT_TIME of a request; when MAX_WAIT_TIME> a preset time threshold, promoting the corresponding request to the highest priority; wherein the preset time threshold can be configured, and the default value is 10 μs.

[0010] In some embodiments, the arranging in descending order of the effective priority by a hardware sorting network comprises the following steps: using a Batchers' odd-even merge sort algorithm by a hardware sorting network to complete 8-core priority sorting in a single clock cycle.

[0011] In some embodiments, the dynamically adjusting priority weighting parameters according to historical arbitration data comprises the following steps: dynamically adjusting priority weighting parameters according to historical arbitration data by a dynamic parameter adjustment calculation formula; The dynamic parameter adjustment calculation formula is: alpha_new = alpha_old + beta * (TARGET_LATENCY - actual average latency); Wherein, beta is a learning rate, and TARGET_LATENCY is a preset delay target value.

[0012] To achieve the above object, another aspect of the embodiment of the present application proposes a real-time task arbitration device of a heterogeneous OS cluster, the device comprising: A data acquisition unit is configured to acquire resource request signals, task priority data, global timestamps and resource identifiers of a multi-core processor through a hardware interface; A priority calculation unit is configured to standardize and map the task priority data and dynamically calculate an effective priority based on latency; An arbitration unit is configured to arrange the resource request signals of concurrent resources of the same resource identifier in descending order of the effective priority through a hardware sorting network, and use the global timestamps to determine the highest priority group; A configuration unit is configured to send a resource authorization signal to a winning core and configure a bus route; A parameter adjustment unit is configured to dynamically adjust a priority weighting parameter according to historical arbitration data.

[0013] To achieve the above object, another aspect of the embodiment of the present application proposes an electronic device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the above method when executing the computer program.

[0014] To achieve the above object, another aspect of the embodiment of the present application proposes a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the above method.

[0015] To achieve the above object, another aspect of the embodiment of the present application proposes a computer program product, comprising a computer program, and the computer program is executed by a processor to implement the above method.

[0016] The embodiment of the present application at least has the following beneficial effects: The application provides a real-time task arbitration method for a heterogeneous OS cluster and related equipment, and the application scheme collects resource request signals, task priority data, global time stamps and resource identifiers of a multi-core processor through a hardware interface; the task priority data is standardized mapped, and effective priority is dynamically calculated based on waiting time; for concurrent resource request signals of resources with the same resource identifier, the hardware sorting network is arranged in descending order of effective priority, and the global time stamp is used for time stamp decision for the highest priority group; a resource authorization signal is sent to the winning core and the bus routing is configured; the priority weighting parameter is dynamically adjusted according to historical arbitration data. The application collects various data through a hardware interface, then calculates the effective priority, and then uses the global time stamp for decision arbitration, so that the priority hardware-assisted cross-OS real-time arbitration scheme can be realized. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the application, the drawings needed to be used in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0018] Figure 1 A flowchart of a real-time task arbitration method for a heterogeneous OS cluster provided by an embodiment of the application is shown in the figure. Figure 2 An example flowchart of a real-time task arbitration method for a heterogeneous OS cluster provided by an embodiment of the application is shown in the figure. Figure 3 A structure diagram of a real-time task arbitration device for a heterogeneous OS cluster provided by an embodiment of the application is shown in the figure. Figure 4 A hardware structure diagram of an electronic device provided by an embodiment of the application is shown in the figure. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solutions and advantages of the application more clear, the application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application and not to limit the application. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementation described in the following exemplary embodiments does not represent all the implementations consistent with the embodiments of the application, but is only an example of devices and methods consistent with some aspects of the embodiments of the application as described in the appended claims.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

[0021] Embodiments of the present application provide a real-time task arbitration method for a heterogeneous OS cluster and related equipment, and relate to the technical field of computer. The real-time task arbitration method for a heterogeneous OS cluster provided by the embodiments of the present application can be applied to a terminal, can be applied to a server, and can also be software running in a terminal or a server. In some embodiments, the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, and the like, but is not limited thereto; the server end can be configured as a stand-alone physical server, can be configured as a server cluster or a distributed system composed of multiple physical servers, can be configured as a cloud server providing basic cloud computing services such as cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, and big data and artificial intelligence platform, and the server can also be a node server in a blockchain network; the software can be an application that implements a real-time task arbitration method for a heterogeneous OS cluster, and the like, but is not limited to the above forms.

[0022] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as a program module. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in a distributed computing environment, in which tasks are performed by remote processing devices connected by a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0023] Reference Figure 1 Embodiments of the present application provide a real-time task arbitration method for a heterogeneous OS cluster, which can include but is not limited to S100 to S140, and specifically as follows: S100: Collecting resource request signals, task priority data, global time stamps, and resource identifiers of a multi-core processor through a hardware interface; S110: standardize mapping of the task priority data, and dynamically calculate effective priority based on latency; S120: for the resource request signals concurrent for the resources with the same resource identifier, arrange in descending order of the effective priority by a hardware sorting network, and use the global timestamp for the highest priority group to timestamp the winner; S130: send a resource grant signal to the winning core and configure bus routing; S140: dynamically adjust priority weighting parameters according to historical arbitration data.

[0024] Optionally, the collection of the resource request signal, the task priority data, the global timestamp and the resource identifier of the multi-core processor through the hardware interface comprises the following steps: Collect the RTOS task priority through a coprocessor; Inject the Linux task priority by modifying the kernel spinlock mechanism; Encode the resource identifier through a shared memory block or a hardware accelerator.

[0025] Optionally, the standardization mapping of the task priority data comprises the following steps: Standardize mapping of the task priority data according to a priority standardization calculation formula; The priority standardization calculation formula is: NORM_PRIO= (RAW_PRIO - MIN_SRC) × (MAX_TARGET - MIN_TARGET) / (MAX_SRC - MIN_SRC) + MIN_TARGET; Wherein, MIN_SRC / MAX_SRC is a pre-configured source OS priority range, and MIN_TARGET / MAX_TARGET is a standardized target range.

[0026] Optionally, the dynamic calculation of the effective priority based on latency comprises the following steps: Calculate the effective priority according to an effective priority calculation formula; The effective priority calculation formula is: EFFECTIVE_PRIO=NORM_PRIO+α×(CURRENT_TIME- EQ_TIMESTAMP); Wherein, the attenuation factor α can be configured by hardware, and the default value is 0.05 / μs.

[0027] Optionally, when performing the timestamp-based decision-making for the highest priority group using the global timestamp, the method further includes executing an anti-starvation mechanism, which includes the following steps: Monitor the maximum wait time for the request, MAX_WAIT_TIME; When MAX_WAIT_TIME > preset time threshold, the corresponding request is promoted to the highest priority; wherein, the preset time threshold is configurable, and the default value is 10μs.

[0028] Optionally, the step of sorting by effective priority in descending order through a hardware sorting network includes the following steps: The Batcher odd-even merge sort algorithm is used by a hardware sorting network to complete the priority sorting of 8 cores within a single clock cycle.

[0029] Optionally, the step of dynamically adjusting the priority weighting parameters based on historical arbitration data includes the following steps: The priority weighting parameters are dynamically adjusted based on historical arbitration data using a dynamic parameter tuning formula. The dynamic parameter tuning calculation formula is as follows: α_new = α_old + β × (TARGET_LATENCY - actual average waiting time); Where β is the learning rate and TARGET_LATENCY is the preset delay target value.

[0030] The following sections will provide a detailed description and explanation of some optional embodiments of this application, using specific application examples.

[0031] refer to Figure 2 This embodiment may include the following solutions: 1. Data Acquisition Layer (Hardware Signal Acquisition): Target of collection: Request signals: REQ[7:0] signals sent by each CPU core (ARM / RISC-V, etc.) through dedicated hardware pins (example of an 8-core cluster).

[0032] Priority data: 4-bit hardware priority code PRIO[3:0] accompanying the request (RTOS task direct mapping, Linux injected through kernel module).

[0033] Timestamp: 32-bit global clock TS[31:0] generated by a high-precision timer (precision ≤100ns).

[0034] Resource identifier: The ID of the requested shared resource RES_ID[5:0] (such as a memory block, hardware accelerator).

[0035] Data source: RTOS side: Task triggers system call is captured by co-processor.

[0036] Linux side: Priority injection instruction is inserted by modifying kernel spinlock mechanism.

[0037] Hardware support: Global Interrupt Controller (GIC) extended arbitration interface.

[0038] 2. Preprocessing layer (data normalization): Processing steps: (1) Priority normalization.

[0039] Principle: Unify different OS priority scales (e.g. Linux 0-139 -> RTOS 0-15).

[0040] Priority normalization calculation formula: NORM_PRIO= (RAW_PRIO - MIN_SRC) × (MAX_TARGET - MIN_TARGET) / (MAX_SRC - MIN_SRC) + MIN_TARGET; RAW_PRIO: Raw priority (from PRIO[3:0]).

[0041] MIN_SRC / MAX_SRC: Source OS priority range (pre-burned in register).

[0042] MIN_TARGET / MAX_TARGET: Target normalized range (0-15).

[0043] (2) Time-sensitive weighting: Principle: Dynamically raise the priority of tasks waiting for timeout.

[0044] Effective priority calculation formula: EFFECTIVE_PRIO=NORM_PRIO+α×(CURRENT_TIME- EQ_TIMESTAMP); Where, the decay factor α can be configured by hardware, the default value is 0.05 / μs.

[0045] CURRENT_TIME: Current global clock value.

[0046] REQ_TIMESTAMP: Request initial timestamp.

[0047] 3. Arbitration core layer (hardware decision logic): Processing steps: (1) Conflict detection.

[0048] Principle: Concurrent requests for the same RES_ID generate a conflict vector, CONFLICT_VEC.

[0049] Hardware implementation: Resource ID comparator array, output conflict bitmap.

[0050] (2) Multi-stage arbitration.

[0051] Stage 1: Priority ordering.

[0052] All requests within a conflict group are ordered in descending order of EFFECTIVE_PRIO.

[0053] Hardware ordering network (e.g. Batcher Odd-Even Merge Sort) is used.

[0054] Output priority queue, PRIO_QUEUE[0…7].

[0055] Stage 2: Time tie-breaker.

[0056] Compare REQ_TIMESTAMP for requests within the highest priority group.

[0057] The request with the smallest timestamp wins (FIFO strategy).

[0058] Output winning core ID, WINNER_CORE_ID.

[0059] (3) Starvation prevention.

[0060] Principle: Monitor the maximum wait time, MAX_WAIT_TIME.

[0061] Action: If MAX_WAIT_TIME > THRESHOLD (e.g. 10 μs), forcibly promote the request priority to the highest.

[0062] 4. Result execution layer (hardware control): Data processing: Grant signal generation: Send GRANT signal to the winning core, along with the resource access token, TOKEN[15:0].

[0063] Resource mapping: Configure the bus matrix (e.g. NIC-400) to route the RES_ID corresponding resource to the winning core.

[0064] State update: Write arbitration log register (winning core ID / timestamp / priority).

[0065] Update wait time counter, WAIT_CYCLES[31:0].

[0066] 5. Feedback layer (system optimization): Data closed loop: Arbitration efficiency analysis: Collect average waiting time = Σ (GRANT_TIMESTAMP - REQ_TIMESTAMP) / total grant times.

[0067] Calculate priority inversion times (high priority requests are blocked by low priority).

[0068] Dynamic parameter adjustment: Adjust the decay factor α according to historical data: α_new = α_old + β × (TARGET_LATENCY - actual average waiting time).

[0069] β: learning rate (default 0.01).

[0070] TARGET_LATENCY: SLA required latency (e.g. 5μs).

[0071] Key innovations of the embodiment scheme: 1. Hardware acceleration pipeline: arbitration time ≤ 3 clock cycles (delay < 3ns at 1GHz frequency); use dedicated hardware sequencer instead of traditional software queue; 2. Cross-OS priority unification: support arbitrary OS priority model through programmable mapping table; 3. Time and space joint arbitration: priority dominance + timestamp assistance + anti-starvation compensation triple guarantee; 4. Closed loop optimization: α factor dynamic adjustment based on historical data to realize SLA adaptation.

[0072] The embodiment scheme realizes the key path through hardware to ensure that the RTOS hard real-time requirements (delay < 10μs) are met in the AMP / SMP hybrid environment, and at the same time, the fairness of Linux non-real-time tasks is optimized by using the feedback mechanism.

[0073] Advantages: The embodiment scheme realizes three technical breakthroughs through data flow closed loop design: 1. Hard real-time guarantee: 3 clock cycle arbitration is realized through hardware sequencing network, meeting the requirements of ASIL-D level safety system; 2. Seamless collaboration across OS: programmable priority mapping table supports arbitrary OS scheduling model extension; 3. Dynamic fairness: time and space joint arbitration + closed loop feedback mechanism effectively optimizes the high / low priority task blocking time ratio; 4. Controllable hardware cost: effectively reduces the area of arbitrator and power consumption.

[0074] ReferenceFigure 3 The embodiment of the application further provides a real-time task arbitration device of a heterogeneous OS cluster, which can realize the real-time task arbitration method of the heterogeneous OS cluster. The data acquisition unit is configured to acquire resource request signals, task priority data, global time stamps and resource identifiers of the multi-core processor through a hardware interface. The priority calculation unit is configured to perform standardized mapping on the task priority data and dynamically calculate effective priorities based on waiting time. The arbitration unit is configured to arrange the resource request signals of concurrent resources with the same resource identifier in descending order of the effective priorities through a hardware sorting network, and perform time stamp decision-making on the highest priority group by using the global time stamps. The configuration unit is configured to send a resource authorization signal to a winning core and configure bus routing. The parameter adjustment unit is configured to dynamically adjust priority weighting parameters according to historical arbitration data.

[0075] It can be understood that the content in the method embodiment is applicable to the device embodiment, the device embodiment specifically realizes the functions of the method embodiment, and achieves the same beneficial effects as the method embodiment.

[0076] Next, some optional embodiments of the application will be described and explained in detail with reference to specific application examples.

[0077] The embodiment of the application further provides an electronic device, which comprises a memory and a processor. The memory stores a computer program, and the processor realizes the method of the embodiment of the application when executing the computer program. The electronic device can be any intelligent terminal, such as a tablet computer or a vehicle-mounted computer.

[0078] It can be understood that the content in the method embodiment is applicable to the device embodiment, the device embodiment specifically realizes the functions of the method embodiment, and achieves the same beneficial effects as the method embodiment.

[0079] Please refer to Figure 4 , Figure 4 The hardware structure of the electronic device of another embodiment is illustrated, and the electronic device comprises: The processor 401 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits, and is configured to execute related programs to implement the technical solutions provided by the embodiments of the present application. The memory 402 can be implemented by a ROM (Read Only Memory), a static storage device, a dynamic storage device, or a RAM (Random Access Memory), and the like. The memory 402 can store an operating system and other application programs. When the technical solutions provided by the embodiments of the present application are implemented by software or firmware, the related program codes are stored in the memory 402 and are called and executed by the processor 401 to implement the method of the embodiments of the present application. The input / output interface 403 is configured to implement information input and output. The communication interface 404 is configured to implement the communication interaction between the device and other devices. The communication can be implemented by a wired manner (for example, a USB, a network cable, or the like) or a wireless manner (for example, a mobile network, WIFI, Bluetooth, or the like). The bus 405 is configured to transmit information between various components (for example, the processor 401, the memory 402, the input / output interface 403, and the communication interface 404) of the device. The processor 401, the memory 402, the input / output interface 403, and the communication interface 404 are connected to each other through the bus 405 to realize the communication connection between the device.

[0080] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the method of the present application.

[0081] It can be understood that the content in the above method embodiments is applicable to the storage medium embodiments. The storage medium embodiments specifically implement the functions of the above method embodiments, and achieve the same beneficial effects as the above method embodiments.

[0082] The embodiments of the present application further provide a computer program product, which includes a computer program. The computer program is executed by a processor to implement the above method.

[0083] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory can include a high-speed random access memory and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory can optionally include a memory disposed remotely from the processor, which can be connected to the processor through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0084] The embodiments described in the embodiments of the present application are used to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0085] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and can include more or fewer steps than shown in the figures, or combine certain steps, or different steps.

[0086] The device embodiments described above are only schematic, and the units described as separate components can or can not be physically separate, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0087] Those skilled in the art can understand that all or some of the steps in the above disclosed method, the functional modules / units in the system and the device can be implemented as software, firmware, hardware and their appropriate combinations.

[0088] The terms "first", "second", "third", "fourth" and the like used in the specification of the present application and the above-described drawings, if any, are used to distinguish similar objects, and do not necessarily have to describe a particular order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to only those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0089] It should be understood that, in the application, "at least one" refers to one or more, and "multiple" refers to two or more. "And / or" is used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, "A and / or B" can represent three cases of only A, only B, and A and B existing at the same time, wherein A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it. "At least one of the following" or similar expressions means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b or c can represent a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, and c can be single or multiple.

[0090] In several embodiments provided in the application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative, for example, the division of the above units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed units can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0091] The units described above as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0092] In addition, the functional units in each embodiment of the application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0093] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application, essentially or in other words, the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes multiple instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program storage media.

[0094] The preferred embodiments of the embodiments of the present application are described above with reference to the accompanying drawings, and are not limited to the scope of the embodiments of the present application. Any modifications, equivalent replacements and improvements made by those skilled in the art without departing from the scope and essence of the embodiments of the present application shall be within the scope of the embodiments of the present application.

Claims

1. A real-time task arbitration method for a heterogeneous OS cluster, characterized in that, The method comprises the following steps: Collecting resource request signals, task priority data, global timestamps and resource identifiers of a multi-core processor through a hardware interface; Standardizing mapping of the task priority data and dynamically calculating effective priorities based on waiting time; For the resource request signals concurrent for the resources of the same resource identifier, arranging the signals in descending order of the effective priorities through a hardware sorting network, and using the global timestamps to timestamp the highest priority group; Sending a resource authorization signal to the winning core and configuring bus routing; Dynamically adjusting priority weighting parameters according to historical arbitration data.

2. The real-time task arbitration method of a heterogeneous OS cluster according to claim 1, characterized in that, The collecting of the resource request signals, the task priority data, the global timestamps and the resource identifiers of the multi-core processor through the hardware interface comprises the following steps: Collecting RTOS task priorities through a coprocessor; Injecting Linux task priorities by modifying a kernel spinlock mechanism; Coding the resource identifiers through a shared memory block or a hardware accelerator.

3. The real-time task arbitration method of a heterogeneous OS cluster according to claim 1, wherein, The standardizing mapping of the task priority data comprises the following steps: Standardizing mapping of the task priority data according to a priority standardization calculation formula; The priority standardization calculation formula is: NORM_PRIO = (RAW_PRIO - MIN_SRC) × (MAX_TARGET - MIN_TARGET) / (MAX_SRC - MIN_SRC) + MIN_TARGET; wherein MIN_SRC / MAX_SRC is a pre-configured source OS priority range, and MIN_TARGET / MAX_TARGET is a standardized target range.

4. The real-time task arbitration method of a heterogeneous OS cluster according to claim 3, characterized in that, The dynamically calculating of the effective priorities based on the waiting time comprises the following steps: Calculating effective priorities according to an effective priority calculation formula; The effective priority calculation formula is: EFFECTIVE_PRIO = NORM_PRIO + α × (CURRENT_TIME - EQ_TIMESTAMP); wherein the decay factor α can be configured by hardware, and the default value is 0.05 / μs.

5. The real-time task arbitration method of a heterogeneous OS cluster according to claim 1, wherein, When the timestamping of the highest priority group using the global timestamps is performed, a starvation prevention mechanism is further executed, which comprises the following steps: Monitoring a maximum waiting time MAX_WAIT_TIME; When MAX_WAIT_TIME > a preset time threshold, the corresponding request is promoted to the highest priority; wherein the preset time threshold can be configured, and the default value is 10 μs.

6. The real-time task arbitration method of a heterogeneous OS cluster according to claim 1, wherein, The arranging of the resource request signals in descending order of the effective priorities through the hardware sorting network comprises the following steps: Using a Batchers' odd-even merge sorting algorithm through a hardware sorting network to complete 8-core priority sorting within a single clock cycle.

7. The real-time task arbitration method of a heterogeneous OS cluster according to any one of claims 1 to 6, characterized in that, The dynamically adjusting of the priority weighting parameters according to the historical arbitration data comprises the following steps: Dynamically adjusting the priority weighting parameters according to the historical arbitration data using a dynamic parameter adjustment calculation formula; The dynamic parameter adjustment calculation formula is: α_new = α_old + β × (TARGET_LATENCY - actual average latency); wherein β is a learning rate, TARGET_LATENCY is a preset latency target value.

8. A real-time task arbitration device for a heterogeneous OS cluster, characterized in that, The device comprises: a data acquisition unit configured to acquire, through a hardware interface, a resource request signal of a multi-core processor, task priority data, a global timestamp, and a resource identifier; a priority calculation unit configured to perform standardized mapping on the task priority data and dynamically calculate an effective priority based on latency; an arbitration unit configured to, for the resource request signals of concurrent resources of the same resource identifier, arrange the resource request signals in descending order of the effective priority through a hardware sorting network, and use the global timestamp to determine a winner for a highest priority group; a configuration unit configured to send a resource grant signal to the winning core and configure a bus route; a parameter adjustment unit configured to dynamically adjust a priority weighting parameter according to historical arbitration data.

9. An electronic device, comprising: The electronic device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the method of any one of claims 1 to 7.

Images