Method and system for dynamic migration of computing tasks facing heterogeneous multi-core processors

Abstract

The application discloses a computing task dynamic migration method and system for a heterogeneous multi-core processor and belongs to the field of computing migration, wherein the method comprises the following steps: encapsulating application business logic into a standardized computing container which is decoupled from a bottom-layer operating system; deploying the standardized computing container to a high-performance application core or a real-time control core; collecting runtime state parameters in real time by a dynamic migration scheduler to generate a migration decision; when triggering migration, performing an atomized migration process by a state synchronization module, transmitting serialized state data to a target core through an inter-core communication channel; rebuilding a lightweight cross-core execution environment on the target core to restore the business operation of the standardized computing container; and redirecting resource access requests initiated by the standardized computing container to corresponding physical resource locations by a resource virtualization agent layer. The application solves the technical problem that the existing task migration process cannot perceive frequent scheduling, easily causes system shock and is difficult to guarantee the stability of system scheduling.

Description

Technical Field

[0001] This invention relates to the field of computational migration, and more specifically to a method and system for dynamic migration of computational tasks for heterogeneous multi-core processors. Background Technology

[0002] With the widespread application of heterogeneous multi-core processors in industrial control, edge computing, embedded smart terminals and other fields, heterogeneous computing architecture composed of high-performance application cores and real-time control cores has become the mainstream technical solution that takes into account both complex business computing needs and strong real-time control needs. However, existing technologies still have the problem of inefficient and unreliable dynamic migration of computing tasks between heterogeneous cores. Currently, most computing tasks adopt a statically bound deployment mode, with business logic and the underlying operating system deeply coupled. This makes it impossible to flexibly adjust the deployment position of tasks between cores according to runtime load fluctuations, changes in business priorities and energy efficiency management needs. This results in an imbalance in the utilization of heterogeneous computing resources and difficulty in guaranteeing the latency stability of high real-time services. At the same time, existing cross-core migration solutions generally have defects such as insufficient migration atomicity, incomplete context capture and recovery, inability to seamlessly continue cross-core resource access, and frequent scheduling that can easily cause system oscillations. It is difficult to simultaneously meet the requirements of business operation continuity, resource access consistency and system scheduling stability. Summary of the Invention

[0003] This application provides a method and system for dynamic migration of computing tasks for heterogeneous multi-core processors, aiming to solve the technical problem that existing task migration processes cannot detect frequent scheduling, are prone to system instability, and are difficult to guarantee the stability of system scheduling.

[0004] In view of the above problems, this application provides a method and system for dynamic migration of computing tasks for heterogeneous multi-core processors.

[0005] The first aspect disclosed in this application provides a method for dynamic migration of computing tasks for heterogeneous multi-core processors, the method comprising: The application business logic to be deployed is encapsulated into a standardized computing container decoupled from the underlying operating system. The standardized computing container has a pre-set policy label. When the system starts, the standardized computing container is deployed to the high-performance application core or the real-time control core according to the default configuration of the policy label. The dynamic migration scheduler collects the runtime state parameters of the high-performance application core and the real-time control core in real time, and generates a migration decision in combination with the configurable policy engine. When the migration decision indicates that migration is triggered, the state synchronization module executes the atomic migration process, freezes the execution state of the standardized computing container on the source core, captures complete context data, and obtains serialized state data after serialization. The serialized state data is transmitted to the target core through the inter-core communication channel. Based on the serialized state data, a lightweight cross-core execution environment on the target core is reconstructed, and the business operation of the standardized computing container is restored. The resource virtualization proxy layer redirects the resource access requests initiated by the standardized computing container to the corresponding physical resource location based on a globally unified resource namespace.

[0006] Another aspect of this application discloses a dynamic migration system for computing tasks on heterogeneous multi-core processors, the system comprising: The system comprises the following modules: an encapsulation module for encapsulating the application business logic to be deployed into a standardized computing container decoupled from the underlying operating system, wherein the standardized computing container has pre-defined policy tags; a deployment module for deploying the standardized computing container to the high-performance application core or the real-time control core according to the default configuration of the policy tags when the system starts; an acquisition module for collecting runtime state parameters of the high-performance application core and the real-time control core in real time by a dynamic migration scheduler, and generating migration decisions in conjunction with a configurable policy engine; a migration module for executing an atomic migration process by a state synchronization module when the migration decision indicates that migration has been triggered, freezing the execution state of the standardized computing container on the source core, capturing complete context data, and obtaining serialized state data after serialization, and transmitting the serialized state data to the target core through an inter-core communication channel; an execution module for reconstructing a lightweight cross-core execution environment on the target core based on the serialized state data, and restoring the business operation of the standardized computing container; and a redirection module for redirecting resource access requests initiated by the standardized computing container to the corresponding physical resource location by a resource virtualization proxy layer based on a globally unified resource namespace.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages: By encapsulating application business logic into a standardized computing container decoupled from the underlying operating system, and combining dynamic migration scheduling with a configurable policy engine, atomic state synchronization and inter-core transmission processes, lightweight cross-core execution environment reconstruction, and resource access redirection under a globally unified resource namespace, along with a migration anti-oscillation optimization mechanism, seamless dynamic scheduling of computing tasks between high-performance application cores and real-time control cores is achieved. This effectively improves the utilization rate of computing resources of heterogeneous multi-core processors, the stability of real-time business operation, and the overall energy efficiency of the system.

[0008] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a method for dynamic migration of computing tasks for heterogeneous multi-core processors is provided for embodiments of this application. Figure 2 This application provides a schematic diagram of the structure of a computing task dynamic migration system for heterogeneous multi-core processors.

[0010] Explanation of reference numerals in the attached diagram: Encapsulation module 11, Deployment module 12, Acquisition module 13, Migration module 14, Execution module 15, Orientation module 16. Detailed Implementation

[0011] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0012] The overall concept of the technical solution provided in this application is as follows: This application provides a method and system for dynamic migration of computing tasks for heterogeneous multi-core processors. By encapsulating application business logic into a standardized computing container decoupled from the underlying operating system, and combining multi-dimensional policy decisions of the dynamic migration scheduler, atomic state synchronization and migration transmission processes, lightweight cross-core execution environment reconstruction, and resource access redirection under a globally unified resource namespace, along with a migration anti-oscillation optimization mechanism, it can achieve dynamic and flexible scheduling of computing tasks between high-performance application cores and real-time control cores while ensuring seamless business interruption, continuous and consistent resource access, and a safe and controllable migration process. This effectively improves the resource utilization efficiency, real-time business assurance capabilities, and overall system stability of heterogeneous multi-core processors.

[0013] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0014] Example 1, as Figure 1 As shown in the embodiments of this application, a method for dynamic migration of computing tasks for heterogeneous multi-core processors is provided. The heterogeneous multi-core processor includes a high-performance application core and a real-time control core. The method includes: S100: The application business logic to be deployed is encapsulated into a standardized computing container decoupled from the underlying operating system, and the standardized computing container is pre-loaded with policy tags.

[0015] Specifically, the first step is to conduct a full call path analysis of the business logic of the application to be deployed, and to completely extract the code branches and dependent components involved in display driver resource calls such as GPU memory access, display command queue submission, and graphics context creation. The core business code of the application, the graphics API runtime library, the display resource call middleware, and all runtime dependencies are uniformly incorporated into the image building context. Standardized encapsulation is completed through a container image building process that conforms to the Open Container Initiative standard to form a standardized computing container. The standardized computing container specifically refers to a lightweight running unit with a unified image format, process isolation boundary, and resource call entry point. It has an independent file system, process space, and resource namespace, which can completely isolate the application runtime environment of different tenants and avoid the risk of process-level interference and display data leakage caused by the mixing of application runtime environments when multiple tenants share display hardware.

[0016] Subsequently, during the encapsulation process, the system call interception layer and driver interface adaptation layer of the container runtime are used to convert all the native system calls and display driver interface calls that the application originally directly faces the host operating system into standardized call interfaces defined by the container runtime. This achieves decoupling from the underlying operating system. The so-called decoupling from the underlying operating system does not completely block the interaction between the application and the host kernel, but rather eliminates the strong binding dependency of the application on the host operating system version, kernel patch configuration, and native display driver version. This ensures that all display driver resource access requests must enter the kernel mode for processing through the unified call exit of the container, so that every access request has a traceable unified entry point and will not have problems such as call path deviation or kernel security check bypass due to differences in the host system environment.

[0017] After the basic container encapsulation is completed, policy tags are pre-defined in the immutable metadata area and runtime security context of the container image. These policy tags are pre-trusted identity and permission carriers that correspond one-to-one with the kernel-side tenant display security tags. They contain four core fields: tenant identity identifier, display resource access permission boundary, expected runtime isolation environment, and resource lifecycle attributes. The tags are written during the image building phase and verified and solidified by the kernel security module when the container starts. They cannot be tampered with by processes inside the container during operation. When an application inside the container initiates a display driver resource access request, the security management module in kernel mode can directly read the policy tag from the container runtime context, quickly parse out key information such as the requester's identity and target resource permissions, and generate the tenant display security tag based on this.

[0018] S200: When the system starts, the standardized computing container is deployed to the high-performance application core or the real-time control core according to the default configuration of the policy label.

[0019] Specifically, during the system startup phase, the kernel-side container scheduling and resource management module first loads the system's preset container startup list, pulls the standardized computing container images of the corresponding tenants one by one, and verifies the integrity and untampered attributes of their preset policy tags.

[0020] Subsequently, the default configuration built into the policy tag is read, and three core parameters are parsed out: business type attribute, display resource access latency sensitivity, and graphics computing power requirement level. Based on the matching rules between the parameters and the core resource pool, the container is deployed to the corresponding core. Among them, the high-performance application core is a set of dedicated cores that the kernel pre-allocates from the physical CPU for high-computing graphics rendering and batch display processing businesses. These cores adopt a high-throughput scheduling strategy, are equipped with sufficient computing power quotas and cache resources, and can handle high-load display driver access behaviors such as large-volume video memory read and write and batch rendering command submission. They are compatible with cloud graphics workstations and batch desktops. In scenarios such as surface rendering, the real-time control core is a dedicated set of cores pre-isolated by the kernel for highly real-time display interaction and control services. These cores shield unnecessary kernel interrupts and scheduling preemption, and adopt a real-time priority scheduling strategy, which can control the latency of display command response and resource status feedback to the microsecond level. During deployment, the kernel will synchronously write the binding relationship between the container and the corresponding core into the full-link isolation mapping graph of display resources, and solidify the core attributes as the underlying hardware identifier of the tenant security node into the graph node data, ensuring that every display driver resource access request initiated by the container can be traced back to a clear hardware core source.

[0021] S300: The dynamic migration scheduler collects the runtime status parameters of the high-performance application core and the real-time control core in real time, and generates migration decisions in combination with the configurable policy engine.

[0022] Specifically, throughout the entire lifecycle of the server system, the dynamic migration scheduler running in kernel mode continuously collects runtime state parameters of the high-performance application core and the real-time control core at a fixed sampling period of microseconds. The dynamic migration scheduler is a scheduling component that only performs scheduling for standardized computing containers that carry display driver access services. All scheduling actions are monitored by the kernel security module throughout the process and will not break through the existing security isolation boundaries.

[0023] The sampling process directly reads raw data from the kernel scheduling subsystem and the display driver kernel module, without going through user space to avoid the risk of data tampering. For high-performance application cores, the focus is on collecting indicators strongly related to high-load display processing, such as overall CPU utilization, video memory read / write throughput, display command queue backlog length, graphics context switching frequency, and computing power quota utilization of each tenant container. For real-time control cores, the focus is on collecting indicators related to real-time interactive experience, such as interrupt response latency, display command execution latency jitter, real-time process preemption count, and isolation environment operation stability. These runtime state parameters are not general CPU load data. Among them, the command queue backlog directly reflects the congestion risk of accessing display resources, while latency jitter corresponds to the interactive reliability of real-time display services. All sampled data is synchronously written to the dynamic attribute fields of the corresponding nodes in the full-link isolation mapping graph of display resources, ensuring the real-time performance and accuracy of the graph node data.

[0024] After data collection, all status parameters are fed into a configurable policy engine for decision-making. This configurable policy engine is a decision-making component with a built-in multi-dimensional rule set, allowing administrators to dynamically adjust rule thresholds and weights based on business security levels and performance requirements. Its rule base includes performance-oriented rules such as load balancing and latency protection, as well as embedded security constraint rules strongly bound to tenant display security flags. For example, it prohibits tenant containers of different security levels from being deployed across cores, and migration operations must not exceed the original display resource access boundaries of tenants. All security rules are linked with the node constraints of the full-link isolation mapping graph of display resources to ensure that scheduling logic and security control logic are consistent. The policy engine first compares the real-time status parameters with preset thresholds. When it identifies that the high-performance application core is saturated, the display command queue is continuously backed up, causing the display access latency to rise, or the real-time control core latency jitter exceeds the security threshold, posing a risk of real-time business interaction failure, it triggers the migration assessment process.

[0025] The engine then filters candidate containers that meet the migration criteria, verifies whether the permission boundaries and runtime environment attributes in the tenant's displayed security tags match the security domain configuration of the target core, and checks the node relationships in the displayed resource end-to-end isolation mapping graph to confirm that the node consistency, boundary consistency, and lifecycle consistency of the entire link will not be compromised after the migration. Finally, it generates a migration decision that includes the migration object, target core, migration execution timing, and supporting resource quota adjustment plan. At the same time as the decision is generated, the node binding relationships in the isolation mapping graph are pre-updated to ensure that the baseline data for end-to-end consistency verification can take effect synchronously after the migration is executed.

[0026] S400: When the migration decision instruction triggers migration, the state synchronization module executes the atomic migration process, freezes the execution state of the standardized computing container in the source core, captures complete context data, and obtains serialized state data after serialization. The serialized state data is then transmitted to the target core through the inter-core communication channel.

[0027] Specifically, when the migration decision generated by the dynamic migration scheduler officially triggers the migration instruction, the state synchronization module running in kernel mode immediately starts atomic migration. Atomic migration has transactional execution characteristics. The entire operation either completes completely to achieve seamless cross-core switching of containers, or completely rolls back to the state before migration in case of any abnormality in any link. The first step is to freeze the execution state of the standardized computing container in the source kernel. Freezing is a collaborative action between the kernel scheduling layer and the display driver kernel module. First, it blocks all new display driver resource access request entries for the container, and then waits for all atomic calls such as display command submission, video memory read and write that are currently being executed in kernel mode to complete. Finally, it suspends the CPU thread, graphics processor context, video memory page mapping relationship, and display command queue handle corresponding to the container to a static state, ensuring that the business operation state of the container is completely consistent with the display resource access state at the moment of freezing. There is no half-executed call chain that would disrupt the subsequent full-link consistency verification benchmark.

[0028] After the state freeze is completed, the state synchronization module immediately captures the container's complete context data. This complete context data includes general runtime data such as CPU register snapshots and container memory page sets, as well as currently effective tenant display security tag copies, completed security domain configurations, a list of allocated display resource handles, the current value of resource lifecycle tags, and cumulative feature data from access behavior analysis. This ensures that the kernel-side security control mechanism can seamlessly continue the original state after migration without having to re-execute the complete security domain binding and permission verification process.

[0029] Subsequently, the state synchronization module performs serialization processing on the full context data to obtain serialized state data. Serialization refers to converting various types of context data, which are scattered across different subsystems of the kernel and have non-contiguous memory addresses, into a continuous binary data stream according to a preset checksum structure. During the processing, an integrity checksum generated based on the tenant identity and context content is embedded synchronously. This ensures that the data can be stably transmitted through the inter-core link and prevents the data from being tampered with or having bit errors during transmission, thus ensuring strict consistency of tenant security attributes and resource status before and after migration.

[0030] Finally, the state synchronization module transmits the serialized state data to the target core via the inter-core communication channel. This inter-core communication channel is a dedicated high-speed kernel-mode communication link pre-established by the kernel between the high-performance application core and the real-time control core. Unlike ordinary user-mode inter-process communication mechanisms, this channel is monitored by the kernel security module throughout the process, allowing only migration state data that has passed identity verification to pass through. The data transmission does not pass through the user-mode memory space, preventing sensitive data such as tenant display security flags and video memory mapping information from being leaked during the migration process. At the same time as the transmission starts, the state synchronization module pushes a temporary state flag to the full-link isolation mapping map of display resources, marking the corresponding tenant security node as being in the migration state and temporarily suspending the full-link consistency verification of the node to avoid abnormal verification misjudgments caused by the migration transition state.

[0031] S500: Based on the serialized state data, reconstruct the lightweight cross-core execution environment on the target core and restore the business operation of the standardized computing container.

[0032] Specifically, the system first performs dual verification of data integrity and source legitimacy based on the integrity check code embedded in the data. This confirms that the data has not been tampered with during transmission and that the corresponding tenant identity matches the target core's preset security domain configuration. After the verification passes, a deserialization operation is performed to restore the continuous, structured binary data stream into context objects that are distributed and stored in different subsystems of the kernel. Then, the reconstruction process of the lightweight cross-core execution environment is initiated. The lightweight cross-core execution environment is the minimum runtime support environment for the kernel to migrate standardized computing containers that carry display driver access services across kernels. It does not require reloading container images and runtime components. It only reconstructs the core scheduling entities, resource mapping relationships, and security attribute contexts necessary for container service execution and security management in the kernel state.

[0033] During the reconstruction process, the module first restores the CPU execution context and process scheduling entity corresponding to the container, writes the deserialized register snapshot, memory page mapping relationship, and process scheduling priority information into the target kernel's scheduling queue, and completes the basic construction of the general execution environment. Then, it focuses on restoring the kernel-mode resources that are strongly bound to the display driver security management of this solution, including restoring the kernel-mode cache entries of the tenant display security flag, reproducing the security domain binding relationship and the corresponding target resource access boundary, rebuilding the kernel mapping relationship between the display command queue handle and the video memory page, and continuing the current value of the resource lifecycle flag and the accumulated data of access behavior characteristics. This ensures that after the migration, the kernel-side security management module does not need to re-execute the entire process of identity resolution, security domain binding, and permission verification, and can seamlessly inherit the original security control logic.

[0034] Once the entire execution environment has been rebuilt, the kernel security module will perform a fast consistency check on all display resource mapping relationships and security attribute configurations. After confirming that the state is completely consistent with the state before migration, the state synchronization module will officially release the execution freeze state of the container, incorporate it into the target core's scheduling and operation system, restore the normal business operation of the standardized computing container, and simultaneously push node relationship update instructions to the full-link isolation mapping graph of display resources. This will switch the binding affiliation of the tenant security node and display resource node corresponding to the container from the source core to the target core, remove the temporary migration mark of the node, and restore the normal execution of the full-link consistency check.

[0035] S600: The resource virtualization proxy layer, based on a globally unified resource namespace, redirects resource access requests initiated by the standardized computing container to the corresponding physical resource location.

[0036] Specifically, when a tenant application within a standardized computing container initiates requests for accessing display driver resources, such as reading and writing video memory, submitting display commands, or creating a graphics context, the requests are first intercepted by the resource virtualization proxy layer running in kernel mode. The resource virtualization proxy layer is a kernel-mode exclusive middleware layer between the container runtime interface and the physical display driver. It not only undertakes the function of address translation from virtual resources to physical resources, but also deeply integrates with the kernel security management module and the full-link isolation mapping graph of display resources. All redirection operations are subject to the permission constraints of the tenant's display security flag, and will not exceed the preset resource access boundaries throughout the process.

[0037] Before performing address translation, the proxy layer resolves the virtual resource identifier carried in the request based on the global unified resource namespace. The global unified resource namespace is a unified addressing system built by the kernel for all shareable display resources within the server, independent of the physical hardware location. It maps discrete physical resources scattered across different GPU devices, different memory partitions, and different display channels into logically continuous virtual resource numbers with consistent naming rules. Applications within the container can only perceive this set of virtual identifiers and cannot directly obtain the address, distribution, and ownership information of the real physical resources. This achieves deep decoupling between tenant business logic and underlying hardware details at the addressing level. After resolution, the proxy layer first extracts the tenant display security tag attached to the request, verifies the legitimacy of the requester's identity and resource access permissions, and confirms that the request does not exceed the access boundaries such as the accessible memory page range and display command queue range defined by the security domain binding. Then, it synchronously retrieves the node association relationship in the full-link isolation mapping graph of display resources to verify that the authorization link between the virtual resource identifier and the requester's tenant node meets the full-link consistency requirements, avoiding the risk of unauthorized access caused by mapping misalignment.

[0038] After successful verification, the proxy layer retrieves the real physical resource location corresponding to the virtual resource identifier from the namespace mapping table. This includes underlying hardware address information such as the specific GPU physical core number, video memory physical page address, and hardware display command queue channel. Then, it performs a rewrite operation on the address field of the original access request, replacing the virtual resource identifier with the real physical resource address, thus completing the redirection of the access request. At the same time, the path information of this redirection is synchronously written into the corresponding relationship edge of the full-link isolation mapping graph of the display resource, updating the real-time access status of the link. Finally, the redirected legitimate request is sent to the physical display driver for execution.

[0039] Furthermore, in the method provided in the application embodiments, the application business logic to be deployed is encapsulated into a standardized computing container decoupled from the underlying operating system, including: inserting a standardized intermediate interface layer between the application business logic and external calls, wherein the standardized intermediate interface layer takes over all access requests from the application business logic to the underlying operating system; the standardized intermediate interface layer uniformly converts native interface calls from different underlying operating systems into internal standard call instructions; the standardized intermediate interface layer dynamically selects a local execution path or a remote proxy path to complete request processing according to the current operating environment; and encapsulates the application business logic after interface conversion and path adaptation into a standardized computing container decoupled from the underlying operating system.

[0040] Specifically, in the application encapsulation preparation stage of the kernel-mode server display driver security management system, a standardized intermediate interface layer is first inserted between the business logic of the application to be deployed and all external call links such as underlying system calls and display driver interfaces. This standardized intermediate interface layer is a lightweight front-end adaptation component designed to adapt to multiple heterogeneous underlying environments and unify the access entry point for display resources. It deeply aligns with the security tag system and global resource naming conventions within the solution. Its core positioning is to serve as the sole exit point for all underlying accesses on the application side, avoiding the problems of uncontrollable access paths and difficulty in implementing security verification caused by the application directly touching the native system interface.

[0041] After insertion, the standardized intermediate interface layer takes over all access requests from the application business logic to the underlying operating system, especially core call requests related to display driver resources such as video memory address reading and writing, display command queue submission, graphics context creation, and display channel configuration. All of these requests are intercepted and the native delivery process is suspended, and they are uniformly incorporated into the standardized processing pipeline of the interface layer.

[0042] Subsequently, the standardized intermediate interface layer performs interface normalization conversion, unifying the native interface calls of different underlying operating systems into internal standard call instructions. These native interface calls of different underlying operating systems encompass various heterogeneous forms, such as differences in system call numbers between different Linux kernel versions, differences in private interface specifications of display drivers from different GPU manufacturers, and differences in register calls between different server hardware architectures. These differences can cause the same display resource access request to present completely different call forms on different host machines, directly interfering with the kernel-side security tag generation and link verification logic. In contrast, the internal standard call instructions are a globally unified request format defined by the solution, with built-in standardized virtual resource identifier fields, structured request parameters, and security tag bearer bits. They are fully aligned with the kernel-side tenant display security tag parsing rules and the addressing rules of the globally unified resource namespace. During the conversion process, all parameter features strongly bound to the underlying hardware and system version are stripped away, retaining only the resource access requests and security attributes of the business logic itself.

[0043] After unifying the command format, the standardized intermediate interface layer dynamically selects either the local execution path or the remote proxy path to complete the request processing based on the current runtime environment. The local execution path is suitable for scenarios where the container is deployed on a local physical node and can directly access local display hardware resources. The interface layer will reverse-convert the internal standard call commands into the native interface format corresponding to the current host system and then send them to the kernel for processing. The remote proxy path is suitable for distributed deployment scenarios where there are no available local display resources and it is necessary to call remote nodes to share display resources. The interface layer will encapsulate the standard commands into secure transmission messages with integrity verification and identity encryption, and forward them to the corresponding processing module on the remote node for execution through a dedicated remote proxy channel. The dynamic adaptation of the dual paths allows applications to adapt to different resource deployment forms without modifying business code, while maintaining the standardization and security of the request format throughout the process.

[0044] Ultimately, the application business logic that completes interface conversion and path adaptation, standardized intermediate interface layer components, and supporting minimum runtime dependencies are all incorporated into the image building process and encapsulated into a standardized computing container decoupled from the underlying operating system. The container image only retains the standard call entry point and internal adaptation logic, without carrying any native dependencies that are bound to a specific operating system version, driver version, or hardware architecture. This ensures that the container can initiate access to display driver resources in a consistent request form on any compliant host node, achieving complete decoupling between the application runtime environment and the underlying host system.

[0045] Furthermore, in the method provided in the application embodiment, the dynamic migration scheduler collects the runtime state parameters of the high-performance application core and the real-time control core in real time, and generates a migration decision in combination with a configurable strategy engine. This includes: the dynamic migration scheduler reading the load information, task queue length, and power consumption information of the high-performance application core and the real-time control core according to a preset period to form a runtime state parameter set; the configurable strategy engine loading a preset decision rule table, matching each item of the runtime state parameter set with the conditions in the decision rule table; and when the matching result meets the migration triggering condition, the configurable strategy engine outputting a migration decision including the source core identifier, the target core identifier, and the identifier of the standardized computing container to be migrated.

[0046] Specifically, the dynamic migration scheduler, running in kernel mode, serves as the dedicated scheduling and execution unit of the display driver security management system. It reads the running status data of the high-performance application core and the real-time control core according to a preset microsecond-level fixed sampling period, forming a set of runtime status parameters. The dynamic migration scheduler only performs scheduling for the standardized computing containers that carry display driver access services. All collection and decision-making actions are monitored by the kernel security module throughout the process. The sampling period can be flexibly configured according to the real-time requirements of the business, which not only ensures the timeliness of status awareness, but also avoids excessively high sampling frequency from crowding out kernel computing power and interfering with the normal processing flow of the display driver.

[0047] During the data collection process, the scheduler directly reads raw data from the kernel scheduling subsystem and the display driver kernel module, without needing to go through user space to avoid the risk of data tampering. Among them, the load information specifically refers to core indicators that are strongly related to display services, such as GPU computing power utilization, video memory read and write bandwidth utilization, and graphics context switching frequency. The task queue length corresponds to the display command queue backlog depth of each tenant container within the two types of core jurisdictions, directly reflecting the congestion level and response latency risk of display resource access. The power consumption information covers core operating power consumption and dynamic energy consumption data of associated display hardware, which is used to support scheduling decisions from the perspective of energy efficiency. The runtime state parameter set composed of the three types of data is synchronously written to the dynamic attribute fields of the corresponding nodes in the display resource end-to-end isolation mapping graph, ensuring that the graph node status is consistent with the actual running status in real time.

[0048] After completing the status collection, the configurable policy engine loads the pre-configured and security-verified decision rule table. The configurable policy engine is the core decision-making hub for migration scheduling, allowing administrators to adjust rule thresholds and judgment logic according to business scenarios. All rule changes must pass kernel security verification and must not exceed the isolation boundaries and permission constraints defined by the tenant's explicit security flag. The decision rule table is the core basis for the engine to make judgments. The table sets multiple sets of trigger conditions according to business scenarios, including performance conditions such as overload triggering, idle merging, and latency exceeding the standard, as well as security pre-constraints such as security level matching and resource boundary compliance. Each condition corresponds to a clear parameter threshold and judgment logic.

[0049] The engine will match and verify each indicator in the runtime state parameter set with the conditions in the decision rule table. The matching process first performs a security pre-verification, and combined with the node constraints of the display resource end-to-end isolation mapping graph, it selects candidate containers that meet the target core security domain requirements and will not break the end-to-end isolation rules after migration. Then, it compares the core and container's running parameters with performance thresholds one by one. When the core load continuously exceeds the overload threshold, the display command queue backlog reaches the warning line, or the multi-core idle load meets the energy efficiency merging conditions during the business off-peak period, and there are migration objects and target cores that meet the security constraints, it is determined that the migration triggering conditions are met.

[0050] The final configurable strategy engine will output a structured migration decision, which includes clear source core identifiers, target core identifiers, and standardized computing container identifiers to be migrated. The decision will also include the priority of migration execution, the suggested execution time, and the corresponding resource quota adjustment scheme. After the decision is generated, it will be pre-verified with the full-link isolation mapping map of the displayed resources to confirm the consistency of the node relationships after migration, and then sent to the state synchronization module to execute the atomic migration process to avoid the issuance of invalid or illegal migration instructions.

[0051] Furthermore, in the method provided in the application embodiment, the configurable strategy engine supports multi-dimensional decision factor combinations, the decision factors including load information, priority information and energy efficiency management information, and the configurable strategy engine comprehensively judges whether migration needs to be triggered based on the decision factors.

[0052] Specifically, the configurable policy engine running in kernel mode serves as the core decision-making unit for dynamic migration scheduling. It has a built-in rule base and weight calculation model that can be flexibly edited through the kernel security configuration interface. It supports multi-dimensional combination calculations of three types of decision factors: load information, priority information, and energy efficiency management information. All decision logic is always linked with the security constraints of the full-link isolation mapping graph of display resources, ensuring that scheduling decisions do not exceed the permission boundaries and isolation requirements defined by the tenant's display security flag.

[0053] The configurable strategy engine allows administrators to adjust the weighting of various decision factors, trigger thresholds, and combination judgment rules according to business scenarios, adapting to performance, security, and energy efficiency requirements in different scenarios. The adjustment process simultaneously verifies the compatibility of the rules with the global security isolation strategy. Load information, as the first type of decision factor, is a dedicated runtime parameter deeply bound to the display driver's operating characteristics. It covers core data such as the display command queue backlog depth of high-performance application cores and real-time control cores, video memory read / write bandwidth utilization, graphics context switching frequency, GPU computing power quota utilization, and display channel response latency. This data is collected in real-time by the dynamic migration scheduler and synchronously input into the strategy engine. The engine will then compare the real-time load value with the pre-defined load value. The overload threshold and idle threshold are compared one by one to identify overloaded cores that cause increased display access latency due to load saturation, and low-load cores that waste computing power due to idle resources. These serve as the basis for triggering migration. The priority information of the second type of decision factor comes from the policy tags pre-set in the standardized computing container and the level attributes in the tenant display security tags generated on the kernel side. These correspond to the business importance, service level agreement guarantee standards and security isolation levels of different tenants. High-priority real-time display control services have scheduling priority. When low-priority rendering services occupy too many core resources, causing high-priority services to fail to meet latency standards, the engine can trigger the migration of low-priority services to free up resources.

[0054] Meanwhile, the priority factor is also bound to security domain isolation rules. Tenant containers of different security levels cannot be migrated and mixed to the shared resource pool of the same core, ensuring that the scheduling process always meets the security requirements of full-link isolation. The third type of decision factor, energy efficiency management information, includes parameters such as core operating power consumption, display hardware energy consumption, and server overall energy efficiency ratio. It is combined with the time-varying characteristics of business load to make a comprehensive judgment. When multiple cores are in a low-load state during the off-peak period, the engine can trigger container merging and migration, concentrate the scattered business to run on a small number of cores, and shut down the display hardware power supply and clock signal of idle cores to reduce overall energy consumption.

[0055] Meanwhile, energy efficiency adjustments must meet the performance and security requirements of all tenants. Energy efficiency optimization must not lead to excessive business latency or shrinkage of security isolation boundaries. After all three decision factors are input, the strategy engine will perform a weighted comprehensive score according to the pre-configured weight model. First, all migration options that violate isolation rules will be screened out through security constraint pre-verification. Then, the comprehensive score of the remaining feasible solutions will be calculated. Only when the comprehensive load score of a certain core continuously exceeds the threshold and there are target cores and containers to be migrated that meet the security and priority requirements will a decision to trigger migration be officially generated. If only a single factor is triggered but the comprehensive score does not reach the threshold, only a warning message will be generated and no actual migration will be triggered to avoid frequent scheduling causing business jitter and increased security verification overhead.

[0056] Furthermore, in the method provided in the application embodiment, when the migration decision instruction triggers migration, the state synchronization module executes an atomic migration process to freeze the execution state of the standardized computing container in the source core and capture complete context data. This includes: after receiving the migration decision, the state synchronization module issues a freeze command to the source core where the standardized computing container is located; after receiving the freeze command, the source core suspends the instruction execution of the standardized computing container and saves the current CPU register snapshot; based on the suspended standardized computing container, it traverses the user-mode stack heap region in its memory and copies the user-mode stack heap memory image; based on the saved CPU register snapshot and the copied user-mode stack heap memory image, it extracts the resource handles opened by the standardized computing container in the source core; and merges the CPU register snapshot, the user-mode stack heap memory image, and the resource handles into complete context data.

[0057] Specifically, when the migration decision generated by the configurable policy engine officially triggers the migration instruction, the state synchronization module running in kernel mode first performs a pre-verification of the tenant identity, target core affiliation, and security level attached to the migration instruction, confirming that it is consistent with the node constraint rules in the full-link isolation mapping graph of the displayed resources, so as to avoid the scheduling operation from breaking through the preset security isolation boundary.

[0058] After verification, the freezing and context capture phases of the atomic migration process are initiated. Atomic migration has transactional execution characteristics. The entire set of freezing, state capture and data integration operations are either fully executed and enter the subsequent transmission phase, or if an exception occurs in any step, it will all be rolled back to the stable running state before migration. The entire process will not produce incomplete resource binding relationships, residual security marker entries or dangling display resource handles, thus eliminating the risk of display resource leakage, security control misalignment and driver state chaos caused by migration interruption from the root of the mechanism.

[0059] The state synchronization module first issues a freeze command to the source kernel where the standardized computing container is located. This freeze command is different from the process pause signal in ordinary user space. It is a kernel space synchronization signal triggered by the kernel scheduling subsystem and the display driver kernel module. After the command is issued, it will act on the CPU scheduling run queue and the resource access entry of the display driver at the same time, ensuring that the execution of the container's computing instructions and the display resource call operation are paused synchronously.

[0060] Upon receiving the freeze command, the source kernel immediately removes the execution thread corresponding to the container from the run queue, suspends the execution of all user-mode instructions in the standardized computing container, and waits until all currently executing instructions in the processor pipeline have been retired. Then, it fully collects the current values ​​of general-purpose registers, control registers, segment registers, and extended registers related to the acceleration of display instructions, and transfers them to the kernel's dedicated secure memory area, saving them as a CPU register snapshot. This snapshot accurately locks the instruction execution point, intermediate results of the operation, and system call context of the container at the moment of freeze.

[0061] Based on the standardized computing container that has entered a completely static state, the state synchronization module traverses the user-mode stack heap region within its address space page by page according to the memory page boundaries, completely copies all the data of the corresponding memory page and generates an independent integrity verification hash value for each page, thus obtaining the user-mode stack heap memory image. The user-mode stack heap region here not only includes general running states such as the function call stack of application business logic and dynamic heap memory data, but also covers the running state data of the standardized intermediate interface layer, the virtual address mapping table of display resources, the user-mode cache of container pre-set policy tags and other dedicated memory segments that are strongly related to display driver access, ensuring that the copied image completely preserves the application's business running state and the intermediate context of display resource access.

[0062] Subsequently, the state synchronization module, based on the system call context in the saved CPU register snapshot and combined with the interface layer resource call records in the user-mode stack heap memory image, locates all activated resource call entry points of the container, matches them with the kernel-mode global resource management table to extract the corresponding access identifiers, and obtains the resource handles opened by the standardized computing container in the source kernel. These resource handles include not only general system resource identifiers such as file descriptors and inter-process communication handles, but more importantly, they cover display driver-specific resource identifiers that are the core of this solution's management, such as graphics processor context handles, video memory page mapping handles, display command queue handles, and display channel access handles. During the extraction process, kernel-mode security attribute data such as tenant display security flags, security domain binding configurations, and resource lifecycle flags that are deeply bound to these handles are also retrieved simultaneously to ensure that the security management attributes of all display resources can be completely continued after migration without having to re-execute the full identity verification and security domain binding process.

[0063] The final state synchronization module integrates CPU register snapshots, user-mode stack memory images, and all resource handles along with corresponding security attribute data in a structured partition, embeds a global verification identifier generated based on tenant identity, and merges them into complete and tamper-proof context data. This provides a complete and reliable state baseline for subsequent serialization transmission and target kernel execution environment reconstruction. Furthermore, in the method provided in the application embodiment, the atomic migration process further includes: the state synchronization module performs serialization encoding processing on the captured complete context data to generate serialized state data; requests storage space from the target core through the inter-core communication channel, and starts the transmission of the serialized state data after the space allocation is completed; if an abnormality occurs during the transmission process, the state synchronization module terminates the transmission and releases the allocated resources, keeping the original execution state of the standardized computing container unchanged in the source core.

[0064] Specifically, the captured complete context data is first serialized and encoded to generate serialized state data. This serialization and encoding process is not a simple data format conversion as in general scenarios, but a structured encoding operation customized for kernel-mode display resource security management scenarios. It reorganizes various display resource handles, such as CPU register snapshots, user-mode stack heap memory images, graphics processor context handles and video memory mapping handles, which are originally scattered across different kernel subsystems and have non-contiguous physical addresses, as well as the accompanying core security data such as tenant display security tags, security domain binding attributes, and resource lifecycle tags, into a continuous and compact binary data stream according to a preset layered security structure. During the encoding process, an integrity check code and sequence number generated based on the tenant identity key are embedded at a fixed data segment length. This ensures that non-contiguous kernel-mode data can be transmitted stably and orderly through inter-core links, and also prevents data from being tampered with or bit misaligned during transmission. It ensures that the security attributes of the tenant and the access status of display resources are strictly consistent before and after the migration. The final serialized state data is encapsulated using an identifier system aligned with the globally unified resource namespace. The header carries a globally unique migration transaction number and tenant security identifier, which facilitates the target kernel side to quickly identify data ownership and complete pre-permission verification.

[0065] After encoding is completed, the state synchronization module requests dedicated storage space from the target core through the inter-core communication channel. This inter-core communication channel is a dedicated high-speed kernel-mode communication link pre-established by the kernel between the high-performance application core and the real-time control core. It runs entirely at the kernel privilege level, without passing through any user-mode memory, and is under the full supervision of the kernel security module. Only migration control data carrying legitimate tenant security identifiers is allowed to pass through, eliminating the risk of leakage of sensitive data such as tenant display security tags and memory mapping relationships at the transmission link level. The space request instruction carries the migration transaction number, tenant security level, and the total byte length of the serialized state data. After receiving the request, the kernel memory management module of the target core first verifies the compatibility between the tenant security identifier and the local security domain configuration, confirming that the tenant container is allowed to be deployed to the target core and has not violated the established isolation rules. Then, it allocates a contiguous kernel memory space of the corresponding size from the dedicated migration security memory pool. The allocation result and the starting address of the space are returned to the source core's state synchronization module along the original communication channel.

[0066] After space allocation is confirmed, the state synchronization module initiates the transmission of serialized state data segment by segment in sequence. After each data segment is transmitted, it synchronously receives the segment verification result returned by the target core. After all data segments are transmitted, a global integrity verification is performed. Throughout the transmission process, the state synchronization module pushes a temporary marker during migration to the display resource full-link isolation mapping graph, marking the corresponding tenant security node as being in the transaction execution state, temporarily suspending the full-link consistency verification of that link to avoid abnormal verification misjudgments caused by the transition state. If any abnormal situation occurs during the transmission process, such as link interruption, segment verification failure, or target core memory abnormality, the state synchronization module will immediately trigger the atomic rollback mechanism, terminate the current transmission process as soon as possible, send a resource release command to the target core to reclaim the allocated memory space and clear all received state data segments.

[0067] Simultaneously, the frozen state of the standardized computing container on the source core is lifted, restoring its original execution state and scheduling permissions on the source core. Temporary markers during migration are removed from the isolation mapping graph, and the normal execution of the end-to-end consistency check is restored. This ensures that the entire migration process either executes successfully or completely reverts to the initial stable state before migration, without any residual half-complete resource allocation or security attribute changes.

[0068] Furthermore, in the method provided in the application embodiment, based on the serialized state data, the lightweight cross-core execution environment on the target core is reconstructed, and the business operation of the standardized computing container is restored. This includes: the lightweight cross-core execution environment receiving the serialized state data on the target core side and deserializing and decoding the serialized state data to restore it to complete context data; reconstructing the user-mode stack heap structure in the target core memory according to the memory layout information in the complete context data, and simultaneously writing the CPU register snapshot contained in the complete context data into the target core register group; and based on the reconstructed user-mode stack heap structure and the written CPU register snapshot, setting the program counter to the execution position before migration, and restoring the business operation of the standardized computing container.

[0069] Specifically, the system first performs dual verification of source legitimacy and security domain access based on the migration transaction number and tenant security identifier in the data header. This confirms that the data comes from an authorized source core migration transaction and that the corresponding tenant's security level complies with the target core's isolation and control rules. After the verification is passed, the serialized state data is deserialized and decoded to restore it into a complete context data with a complete structure. The lightweight cross-core execution environment here is the smallest running support unit for cross-core migration, which is customized by the kernel for standardized computing containers that carry display driver access services. It only completes the container execution context restoration and security control attribute continuation in kernel mode, minimizing the business interruption time caused by migration while ensuring the integrity of the security control logic.

[0070] The deserialization decoding process strictly matches the layered security encoding rules of the source end, verifies the integrity check code and sequence number embedded in the data segment by segment, and confirms that no tampering, packet loss or bit misalignment has occurred during transmission. Then, it restores the set of display resource handles such as CPU register snapshot, user-mode stack heap memory image, graphics processor context handle, and video memory mapping handle, as well as core security attribute data such as tenant display security mark, security domain binding configuration, resource lifecycle mark, and access behavior feature accumulation data that are deeply bound to the security system of this solution. This ensures that the restored context is completely consistent with the computing state, display resource state and security control state at the moment the source core is frozen.

[0071] After decoding, the component reconstructs the user-mode stack heap structure in the container-specific address space of the target core based on the memory layout information attached to the complete context data. The so-called memory layout information refers to the starting address, segment length, and read / write permission attributes of each memory segment in the original container address space, such as the stack area, dynamic heap area, and standardized intermediate interface layer runtime area, which are synchronously recorded during the serialization stage. During the reconstruction process, memory pages with corresponding permissions are allocated according to the original layout, and stack heap memory image data is written page by page. At the same time, the virtual resource mapping table of the standardized intermediate interface layer is restored synchronously to ensure that the display resource access requests initiated by the application after migration can still be addressed normally based on the virtual identifier of the globally unified resource namespace. There will be no problems such as resource address invalidation or call path offset due to cross-core deployment, ensuring that the subsequent redirection operation of the kernel-side resource virtualization proxy layer can be executed normally.

[0072] At the same time, the component writes a snapshot of the CPU registers from the complete context data to the hardware register group of the corresponding execution thread of the target core, completely covering the state of general-purpose registers, control registers, and extended registers related to display instruction acceleration. This ensures that the state at the hardware execution level is fully aligned with that before the migration, avoiding computational deviations or contextual errors in subsequent display instruction execution.

[0073] Once the stack structure and register states are fully reconstructed, the component precisely points the program counter to the instruction execution location at the moment of freezing before the migration. The program counter is a core register in the CPU that records the address of an instruction to be executed. This operation allows the container to seamlessly resume execution from the paused instruction point, completely unaware of the cross-core migration occurring at the business layer. Before officially resuming operation, the kernel security module performs a fast end-to-end consistency check, verifying whether the reconstructed resource handles, security tags, and node associations in the displayed end-to-end isolation mapping graph match. Only after confirming that security domain bindings and resource access boundaries have not shifted is the container thread added to the target core's runtime scheduling queue, restoring the normal business operation of the standardized computing container. Simultaneously, the tenant node ownership information in the isolation mapping graph is updated, temporary state tags during migration are removed, and the normal execution of the end-to-end consistency check is resumed. Furthermore, in the method provided in the application embodiment, the resource virtualization proxy layer redirects the resource access request initiated by the standardized computing container to the corresponding physical resource address based on the globally unified resource namespace. This includes: the resource virtualization proxy layer is configured with a mapping table between the globally unified resource namespace and physical addresses; when the standardized computing container initiates a resource access request, it extracts the globally unique identifier carried in the request; the resource virtualization proxy layer queries the current physical address corresponding to the globally unique identifier in the mapping table and redirects the resource access request to the current physical address, thereby completing the seamless switching of cross-core resource access.

[0074] Specifically, the resource virtualization proxy layer running in kernel mode serves as the unified entry point for all display driver resource access requests. It pre-configures and maintains a mapping table between the global unified resource namespace and physical addresses, synchronized with the display resource end-to-end isolation mapping graph. This global unified resource namespace is a unified addressing system built by the kernel for all multi-tenant shared display driver resources within the server, completely independent of hardware topology and core ownership. It integrates discrete physical display resources distributed across different GPU devices, different memory partitions, different display command queues, and managed by high-performance application cores and real-time control cores. Resources are uniformly mapped into a logically continuous and rule-consistent virtual resource identification system. Applications within the container can only perceive this set of virtual identifiers and cannot access the details of the real hardware addresses. This achieves deep decoupling between the tenant's business logic and the underlying hardware from the addressing layer. The mapping relationship table is the core carrier of this namespace. Each record in the table corresponds to a set of mapping relationships between virtual identifiers and physical addresses. It is also bound to security attributes such as the resource's tenant ownership, access permission boundaries, and resource lifecycle status. The data is updated in real time with resource scheduling, cross-core migration, and resource reuse operations, and always maintains the same source and consistency with the node data of the end-to-end isolated mapping graph.

[0075] When a tenant application within a standardized computing container initiates resource access requests such as video memory read / write, display command submission, and graphics context creation, thanks to the pre-normalization processing of the container's built-in standardized intermediate interface layer, the request message carries a globally unique identifier corresponding to the target resource. After intercepting the request, the resource virtualization proxy layer first performs a pre-verification of the requester's identity and permissions by combining the tenant's display security mark, confirming that the request does not exceed the scope of accessible resources defined by the security domain binding. Then, it extracts the globally unique identifier carried in the request. The globally unique identifier is a virtual identity assigned to each display resource under the globally unified resource namespace. It has the characteristics of being unique across the entire system, not being directly related to the physical location, and being able to be bound to security attribute verification. Even if the container completes cross-core migration, the resource identifier held internally does not need to be modified to maintain the validity of the access logic.

[0076] After the identifier extraction is complete, the resource virtualization proxy layer queries the mapping table for the current physical address corresponding to the globally unique identifier. This current physical address encompasses underlying hardware address information such as the specific GPU physical core number, the starting address of the video memory physical page, the hardware display command queue channel number, and the display controller port. It is updated in real-time with dynamic operations such as cross-core migration, resource reallocation, and resource reuse and reclamation, rather than being a fixed static address. After the query and matching are complete, the proxy layer performs a transparent rewrite operation on the address field of the original access request, replacing the virtual globally unique identifier with the real physical resource address, and then forwarding the resource access request. After redirection to the corresponding current physical address, the application is sent to the physical display driver for execution. The entire address translation process is completely transparent to the upper-layer standardized computing container and application business logic. Even if the container undergoes cross-core migration from the source core to the target core, it is only necessary to synchronously update the physical address of the corresponding identifier in the mapping table. The application's resource access link can be seamlessly continued, thus completing the seamless switching of cross-core resource access. At the same time, the proxy layer will synchronously write the path information of this redirection into the corresponding edge of the full-link isolation mapping graph of the display resource, update the real-time access status of the link, and provide accurate path data support for subsequent full-link consistency verification.

[0077] Furthermore, in the method provided in the application embodiment, the method further includes anti-oscillation optimization: the dynamic migration scheduler records the performance change data of the high-performance application core and the real-time control core before and after each migration; adjusts the migration trigger threshold in the configurable strategy engine according to the performance change data, and sets a migration cooldown time window for the standardized computing container that has completed the migration, and prohibits the initiation of migration decisions for the standardized computing container again within the migration cooldown time window.

[0078] Specifically, the system first records the performance changes of the high-performance application cores and real-time control cores before and after each migration. These performance changes are not generalized metrics like CPU utilization, but rather core operating parameters deeply tied to the characteristics of display-driven services. This includes benchmark performance data such as average response latency of the display command queue, effective utilization of video memory bandwidth, real-time service jitter rate, and effective computing power output of the two types of cores in the steady-state phase before migration, as well as corresponding metrics in the steady-state phase after migration. Simultaneously, the system records migration cost data such as context capture time, inter-core transmission overhead, and service interruption window duration. The scheduler calculates the actual net benefit of the migration by comparing the performance difference before and after migration, identifying invalid migration scenarios triggered by short-term load fluctuations, or where post-migration performance fails to meet expectations or even declines, providing data for subsequent strategy adjustments.

[0079] The scheduler then dynamically adjusts the migration trigger threshold in the configurable policy engine based on accumulated performance change data. The migration trigger threshold is a critical value in the policy engine used to determine whether decision factors such as load and latency have reached the migration trigger condition. It is a core parameter that determines the scheduling sensitivity. If the proportion of invalid migrations is high within the statistical period, or if the net benefit after migration is frequently lower than the preset benchmark, the scheduler will correspondingly raise the trigger threshold of load and latency decision factors to increase the trigger threshold for migration decisions and avoid unnecessary cross-core scheduling caused by short-term load spikes. If there is a long-term core load imbalance but no migration is triggered, and the overall resource utilization remains low, the threshold will be appropriately lowered to release scheduling flexibility. During the adjustment process, the compatibility of the rules with the security constraints of the full-link isolation mapping map of display resources will be checked simultaneously to ensure that the threshold adjustment does not exceed the isolation boundary and permission range defined by the tenant's display security mark.

[0080] Meanwhile, the scheduler sets an independent migration cooldown window for each standardized computing container that has just completed migration. This migration cooldown window is the time interval during which a container is forcibly included in the scheduling protection after completing cross-core migration and is prohibited from initiating migration decisions again. The window length is dynamically adapted based on the net performance gain of this migration. The lower the net migration gain, the longer the window length. During the migration cooldown window, even if the policy engine detects fluctuations in core load, it will directly exclude the container from the candidate migration objects, only continuously monitor its running status and performance data, and will not generate migration instructions for the container until the cooldown period ends before it is reinstated into the global scheduling resource pool.

[0081] In summary, the method for dynamic migration of computing tasks for heterogeneous multi-core processors provided in this application has the following technical effects: By encapsulating application business logic into a standardized computing container decoupled from the underlying operating system, and combining dynamic migration scheduling with a configurable policy engine, atomic state synchronization and inter-core transmission processes, lightweight cross-core execution environment reconstruction, and resource access redirection under a globally unified resource namespace, along with a migration anti-oscillation optimization mechanism, seamless dynamic scheduling of computing tasks between high-performance application cores and real-time control cores is achieved. This effectively improves the utilization rate of computing resources of heterogeneous multi-core processors, the stability of real-time business operation, and the overall energy efficiency of the system.

[0082] Example 2, based on the same inventive concept as the method for dynamic migration of computing tasks for heterogeneous multi-core processors in the foregoing examples, such as... Figure 2 As shown in the figure, this application provides a dynamic migration system for computing tasks on heterogeneous multi-core processors. The system includes: The encapsulation module 11 encapsulates the application business logic to be deployed into a standardized computing container decoupled from the underlying operating system, wherein the standardized computing container has a pre-set policy label; the deployment module 12 deploys the standardized computing container to the high-performance application core or the real-time control core according to the default configuration of the policy label when the system starts; the acquisition module 13 collects the runtime state parameters of the high-performance application core and the real-time control core in real time by the dynamic migration scheduler, and generates a migration decision in combination with the configurable policy engine; the migration module 14 executes an atomic migration process by the state synchronization module when the migration decision indicates that migration is triggered, freezes the execution state of the standardized computing container on the source core, captures complete context data, and obtains serialized state data after serialization, and transmits the serialized state data to the target core through the inter-core communication channel; the execution module 15 reconstructs the lightweight cross-core execution environment on the target core based on the serialized state data, and restores the business operation of the standardized computing container; the redirection module 16 redirects the resource access request initiated by the standardized computing container to the corresponding physical resource location based on the global unified resource namespace by the resource virtualization proxy layer.

[0083] Furthermore, the encapsulation module 11 is also used to perform the following steps: inserting a standardized intermediate interface layer between the application business logic and external calls, wherein the standardized intermediate interface layer takes over all access requests from the application business logic to the underlying operating system; wherein the standardized intermediate interface layer uniformly converts the native interface calls of different underlying operating systems into internal standard call instructions; wherein the standardized intermediate interface layer dynamically selects a local execution path or a remote proxy path to complete the request processing according to the current running environment; and encapsulating the application business logic after interface conversion and path adaptation into a standardized computing container decoupled from the underlying operating system.

[0084] Furthermore, the acquisition module 13 is also used to perform the following steps: the dynamic migration scheduler reads the load information, task queue length and power consumption information of the high-performance application core and the real-time control core according to a preset period to form a runtime state parameter set; the configurable strategy engine loads a preset decision rule table and matches the runtime state parameter set item by item with the conditions in the decision rule table; when the matching result meets the migration triggering condition, the configurable strategy engine outputs a migration decision including the source core identifier, the target core identifier and the identifier of the standardized computing container to be migrated.

[0085] Furthermore, the acquisition module 13 is also used to perform the following steps: the configurable strategy engine supports multi-dimensional decision factor combinations, the decision factors include load information, priority information and energy efficiency management information, and the configurable strategy engine comprehensively judges whether migration needs to be triggered based on the decision factors.

[0086] Furthermore, the migration module 14 is also used to perform the following steps: after receiving the migration decision, the state synchronization module issues a freeze command to the source core where the standardized computing container is located; after receiving the freeze command, the source core suspends the instruction execution of the standardized computing container and saves the current CPU register snapshot; based on the suspended standardized computing container, it traverses the user-mode stack heap region in its memory and copies the user-mode stack heap memory image; based on the saved CPU register snapshot and the copied user-mode stack heap memory image, it extracts the resource handles opened by the standardized computing container in the source core; and merges the CPU register snapshot, the user-mode stack heap memory image, and the resource handles into complete context data.

[0087] Furthermore, the migration module 14 is also used to perform the following steps: the state synchronization module performs serialization encoding processing on the captured complete context data to generate serialized state data; requests storage space from the target core through the inter-core communication channel, and starts the transmission of the serialized state data after the space allocation is completed; if an abnormality occurs during the transmission, the state synchronization module terminates the transmission and releases the allocated resources, keeping the original execution state of the standardized computing container unchanged in the source core.

[0088] Furthermore, the execution module 15 is also used to perform the following steps: the lightweight cross-core execution environment receives the serialized state data on the target core side, and performs deserialization decoding on the serialized state data to restore it to complete context data; based on the memory layout information in the complete context data, the user-mode stack heap structure is reconstructed in the target core memory, and at the same time, the CPU register snapshot contained in the complete context data is written into the target core register group; based on the reconstructed user-mode stack heap structure and the written CPU register snapshot, the program counter is set to the execution position before migration, and the business operation of the standardized computing container is restored.

[0089] Furthermore, the redirection module 16 is also used to perform the following steps: the resource virtualization proxy layer is configured with a mapping table between a globally unified resource namespace and a physical address; when the standardized computing container initiates a resource access request, the globally unique identifier carried in the request is extracted; the resource virtualization proxy layer queries the mapping table for the current physical address corresponding to the globally unique identifier, and redirects the resource access request to the current physical address, thereby completing the seamless switching of cross-core resource access.

[0090] Furthermore, the acquisition module 13 is also used to perform the following steps: the dynamic migration scheduler records the performance change data of the high-performance application core and the real-time control core before and after each migration; adjusts the migration trigger threshold in the configurable strategy engine according to the performance change data, and sets a migration cooldown time window for the standardized computing container that has completed the migration, and prohibits the standardized computing container from initiating migration decisions again within the migration cooldown time window.

[0091] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for dynamic migration of computing tasks for heterogeneous multi-core processors, characterized in that, The heterogeneous multi-core processor includes a high-performance application core and a real-time control core, and the method includes: The application business logic to be deployed is encapsulated into a standardized computing container decoupled from the underlying operating system, and the standardized computing container is pre-loaded with policy tags; When the system starts, the standardized computing container is deployed to the high-performance application core or the real-time control core according to the default configuration of the policy label; The dynamic migration scheduler collects the runtime status parameters of the high-performance application core and the real-time control core in real time, and generates migration decisions in combination with the configurable policy engine. When the migration decision instruction triggers migration, the state synchronization module executes the atomic migration process, freezes the execution state of the standardized computing container in the source core, captures complete context data, and obtains serialized state data after serialization. The serialized state data is then transmitted to the target core through the inter-core communication channel. Based on the serialized state data, the lightweight cross-core execution environment on the target core is reconstructed, and the business operation of the standardized computing container is restored. The resource virtualization proxy layer, based on a globally unified resource namespace, redirects resource access requests initiated by the standardized computing container to the corresponding physical resource location.

2. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 1, characterized in that, The application's business logic to be deployed is encapsulated into a standardized computing container decoupled from the underlying operating system, including: A standardized intermediate interface layer is inserted between the application business logic and external calls, and the standardized intermediate interface layer takes over all access requests from the application business logic to the underlying operating system. The standardized intermediate interface layer converts native interface calls from different underlying operating systems into unified internal standard call instructions. The standardized intermediate interface layer dynamically selects either a local execution path or a remote proxy path based on the current operating environment to complete the request processing; The application business logic, after completing interface conversion and path adaptation, is encapsulated into a standardized computing container decoupled from the underlying operating system.

3. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 1, characterized in that, The dynamic migration scheduler collects runtime status parameters of the high-performance application core and the real-time control core in real time, and generates migration decisions in conjunction with a configurable policy engine, including: The dynamic migration scheduler reads the load information, task queue length, and power consumption information of the high-performance application core and the real-time control core according to a preset period to form a set of runtime status parameters. The configurable strategy engine loads a preset decision rule table and matches each item of the runtime state parameter set with the conditions in the decision rule table. When the matching result meets the migration triggering condition, the configurable strategy engine outputs a migration decision including the source core identifier, the target core identifier, and the identifier of the standardized computing container to be migrated.

4. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 3, characterized in that, The configurable strategy engine supports multi-dimensional combinations of decision factors, including load information, priority information, and energy efficiency management information. The configurable strategy engine comprehensively determines whether migration needs to be triggered based on the decision factors.

5. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 1, characterized in that, When the migration decision instruction triggers a migration, the state synchronization module executes an atomic migration process, freezing the execution state of the standardized computing container on the source core and capturing complete context data, including: After receiving the migration decision, the state synchronization module issues a freeze command to the source core where the standardized computing container is located. After receiving the freeze command, the source core pauses the execution of instructions in the standardized computing container and saves a snapshot of the current CPU registers. Based on the standardized computing container that has been suspended, traverse the user-mode stack heap region in its memory and copy the user-mode stack heap memory image. Based on the saved CPU register snapshot and the copied user-space stack heap memory image, extract the resource handles opened by the standardized computing container in the source core; The CPU register snapshot, the user-mode stack memory image, and the resource handle are merged into complete context data.

6. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 5, characterized in that, The atomized migration process also includes: The state synchronization module performs serialization encoding on the captured complete context data to generate serialized state data; The inter-core communication channel is used to request storage space from the target core, and the transmission of the serialized state data is initiated after the space allocation is completed. If an abnormality occurs during transmission, the state synchronization module terminates the transmission and releases the allocated resources, maintaining the original execution state of the standardized computing container in the source core.

7. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 1, characterized in that, Based on the serialized state data, the lightweight cross-core execution environment on the target core is reconstructed, and the business operation of the standardized computing container is restored, including: The lightweight cross-core execution environment receives the serialized state data on the target core side and performs deserialization decoding on the serialized state data to restore it to complete context data; Based on the memory layout information in the complete context data, the user-mode stack heap structure is reconstructed in the target core memory. At the same time, the CPU register snapshot contained in the complete context data is written into the target core register group. Based on the reconstructed user-space stack structure and the written CPU register snapshot, the program counter is pointed to the execution position before the migration, and the business operation of the standardized computing container is restored.

8. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 1, characterized in that, The resource virtualization proxy layer, based on a globally unified resource namespace, redirects resource access requests initiated by the standardized computing containers to the corresponding physical resource addresses, including: The resource virtualization proxy layer is configured with a mapping table between a globally unified resource namespace and physical addresses; When the standardized computing container initiates a resource access request, the globally unique identifier carried in the request is extracted; The resource virtualization proxy layer queries the mapping table for the current physical address corresponding to the globally unique identifier, and redirects the resource access request to the current physical address, thus completing the seamless switching of cross-core resource access.

9. The method for dynamic migration of computing tasks for heterogeneous multi-core processors as described in claim 1, characterized in that, The method also includes anti-oscillation optimization: The dynamic migration scheduler records the performance changes of the high-performance application core and the real-time control core before and after each migration. The migration trigger threshold in the configurable policy engine is adjusted based on the performance change data, and a migration cooldown window is set for the standardized computing containers that have completed migration. During the migration cooldown window, migration decisions are prohibited from being initiated again for the standardized computing containers.

10. A dynamic migration system for computing tasks on heterogeneous multi-core processors, characterized in that, The system is used to implement the dynamic migration method for computing tasks oriented towards heterogeneous multi-core processors according to any one of claims 1 to 9, wherein the system comprises: The encapsulation module is used to encapsulate the application business logic to be deployed into a standardized computing container decoupled from the underlying operating system. The standardized computing container has a pre-set policy label. The deployment module is used to deploy the standardized computing container to the high-performance application core or the real-time control core according to the default configuration of the policy tag when the system starts up; The acquisition module is used to collect the runtime status parameters of the high-performance application core and the real-time control core in real time by the dynamic migration scheduler, and generate migration decisions in combination with the configurable strategy engine. The migration module is used to execute an atomic migration process by the state synchronization module when the migration decision instruction triggers the migration, freeze the execution state of the standardized computing container in the source core, capture complete context data, and obtain serialized state data after serialization, and transmit the serialized state data to the target core through the inter-core communication channel; The execution module is used to reconstruct the lightweight cross-core execution environment on the target core based on the serialized state data, and restore the business operation of the standardized computing container; The redirection module is used by the resource virtualization proxy layer to redirect resource access requests initiated by the standardized computing container to the corresponding physical resource location based on the globally unified resource namespace.

Images