A hardware resource dynamic instruction redirection method and device

Abstract

This invention provides a method and apparatus for dynamic instruction redirection of hardware resources, relating to the technical field of terminal device resource management. The method includes: real-time collection of device status information from all connected home terminal devices via the HarmonyOS distributed soft bus, and screening of candidate idle devices in an idle state; matching the execution architecture requirements of the instruction to be migrated with the underlying hardware architecture of the candidate idle devices, and selecting candidate compatible devices that support the execution architecture requirements; constructing a priority mechanism for migration instructions based on the HarmonyOS scheduling framework, calculating dynamic priority weights, and combining these weights to call a device performance evaluation function; constructing a task migration benefit function by comprehensively considering multi-dimensional performance indicators; and finally selecting the optimal target device based on the result of the benefit function. This invention enables the design of a dedicated priority mechanism for cross-device migration instructions under the HarmonyOS native scheduling framework, thereby achieving efficient scheduling of migration tasks under heterogeneous hardware conditions across multiple devices.

Description

Technical Field

[0001] This invention relates to the technical field of terminal device resource management, and specifically to a method and apparatus for dynamic instruction redirection of hardware resources. Background Technology

[0002] HarmonyOS is a distributed operating system independently developed by Huawei for a full-scenario intelligent ecosystem. It adopts a microkernel architecture and distributed soft bus technology to enable seamless collaboration and resource sharing of different types of hardware devices under a unified system framework. It supports cross-device task migration, data flow and hardware calls, enabling one-time development and multi-terminal deployment. Through modular component design, it enhances security, real-time performance and scalability, and is widely compatible with smartphones, tablets, wearable devices, in-vehicle terminals and IoT devices.

[0003] The HarmonyOS native scheduling framework primarily focuses on optimizing multi-task concurrency and resource allocation within local devices in its task scheduling strategy. Its priority determination mechanism dynamically adjusts based on task type, real-time requirements, and resource usage. However, it does not build an independent priority determination and scheduling channel for cross-device migration instructions. It lacks a mechanism for assigning exclusive priority to migration instructions, reserving cross-node resources, and upgrading scheduling levels in multi-device collaborative scenarios. This results in migration tasks potentially failing to obtain continuous and stable execution guarantees under high load or competitive conditions.

[0004] Therefore, a method is needed to design a dedicated priority mechanism for cross-device migration instructions under the HarmonyOS native scheduling framework, so as to achieve efficient scheduling of migration tasks under heterogeneous hardware conditions of multiple devices. Summary of the Invention

[0005] This invention provides a method and apparatus for dynamic instruction redirection of hardware resources, which can realize the design of a dedicated priority mechanism for cross-device migration instructions under the HarmonyOS native scheduling framework, thereby achieving efficient scheduling of migration tasks under heterogeneous hardware conditions of multiple devices.

[0006] A first aspect of the present invention provides a method for dynamic instruction redirection of hardware resources, the method comprising: The device status information of all currently connected home terminal devices is collected through the HarmonyOS distributed soft bus. The device status information is filtered to retain multiple candidate idle devices that are in an idle state; The execution architecture requirements of the instructions to be migrated are adapted and matched with the underlying hardware architecture of the candidate idle devices, and candidate compatible devices that support the execution architecture requirements are retained among the candidate idle devices. A priority mechanism for migration instructions is constructed based on the preset HarmonyOS scheduling framework, and a dynamic priority weight is assigned to each instruction to be migrated. For each of the candidate compatible devices, the device performance evaluation function is invoked based on the dynamic priority weight to construct the task migration benefit function; Based on the calculation results of the task migration benefit function, the target device among the multiple candidate compatible devices is selected as the migration target node of the instruction to be migrated.

[0007] Based on the above technical solutions, preferably, the step of adapting and matching the execution architecture requirements of the instructions to be migrated with the underlying hardware architecture of the candidate idle devices, and retaining candidate compatible devices that support the execution architecture requirements among the candidate idle devices, specifically includes: The instructions to be migrated are converted into a unified intermediate representation vector by Ark Compiler. The intermediate representation vector contains the underlying runtime features on which the execution of the instructions to be migrated depends. For each of the candidate idle devices, the underlying hardware abstraction identifier is retrieved in real time to construct a standardized hardware capability vector; The structural fit between the intermediate representation vector and the hardware capability vector is calculated using a distributed structural matching function, wherein the distributed structural matching function is as follows: Where S represents the structural fit degree. The weight of the k-th fitting item. Let k be the compatibility mapping function between the k-th features. This is the intermediate representation vector corresponding to the k-th fitting item. This is the hardware capability vector corresponding to the kth adaptation item; Candidate idle devices whose structural adaptability is greater than a preset compatibility threshold are identified as candidate compatible devices.

[0008] Based on the above technical solutions, preferably, the priority mechanism for constructing migration instructions based on the preset HarmonyOS scheduling framework, which assigns dynamic priority weights to each instruction to be migrated, specifically includes: A migration priority field is added to the HarmonyOS kernel task control block to mark the instructions to be migrated as an independent priority category that can be recognized by the kernel scheduler; Based on the priority allocation strategy, the real-time level, data dependency degree, and global load distribution of the instruction to be migrated are used as input parameters. The real-time level is obtained by parsing the latency-sensitive feature field in the intermediate representation vector. The data dependency degree is determined by analyzing the size of the distributed cache consistency domain to be accessed by the migration instruction. The global load distribution is determined by the device status information of the candidate compatible device. The real-time performance level, the degree of data dependence, and the global load distribution are combined according to a preset weighting coefficient to form a dynamic priority weight. The dynamic priority weight is written into the migration priority field and used as a performance evaluation factor in the calculation when constructing the task migration benefit function.

[0009] Based on the above technical solutions, preferably, before combining the real-time performance level, the data dependency degree, and the global load distribution according to a preset weighting coefficient to form a dynamic priority weight, the method further includes: According to the execution architecture requirements, the architecture feature parsing module is invoked to parse the computing resource types, computation instruction set complexity, parallelism requirements and latency sensitivity levels involved in the execution architecture requirements, and generate corresponding architecture feature vectors. The architecture feature vector is compared with the global device resource capability matrix to determine the performance bottleneck type of the architecture feature corresponding to the architecture feature vector on different candidate compatible devices, including computing power bottleneck, memory bandwidth bottleneck and network latency bottleneck. Based on the performance bottleneck type, the weighting coefficient corresponding to the real-time level is assigned a weight proportional to the latency sensitivity level; the weighting coefficient corresponding to the data dependency level is assigned a weight proportional to the cache consistency domain access frequency; and the weighting coefficient corresponding to the global load distribution is assigned a weight inversely proportional to the proportion of available computing power of the target device.

[0010] Based on the above technical solutions, preferably, the step of constructing a task migration benefit function by calling the device performance evaluation function based on the dynamic priority weight for each of the candidate compatible devices specifically includes: The device performance evaluation function is invoked, with the real-time computing power index, memory bandwidth index, instruction set matching index, network transmission latency index, and energy efficiency index of the candidate compatible device as input parameters. The real-time computing power index is determined by the number of currently available CPU cores and the GPU computing unit utilization rate of the candidate compatible device. The memory bandwidth index is determined by the ratio of the current throughput rate to the peak throughput rate of the memory controller of the candidate compatible device. The instruction set matching index is determined by the structural adaptability between the intermediate representation vector of the instruction to be migrated and the hardware capability vector of the candidate compatible device. The network transmission latency index is determined by the real-time round-trip latency measurement value between nodes provided by the HarmonyOS distributed soft bus. The energy efficiency index is determined by the unit computing power energy consumption ratio of the candidate compatible device. The dynamic priority weight is used as a weight correction factor to weight and sum the input parameters of each item to obtain the comprehensive performance score. The task migration benefit function is constructed based on the inverse relationship between the comprehensive performance score and the estimated execution time of the instruction to be migrated on the candidate compatible device.

[0011] Based on the above technical solutions, preferably, after selecting the target device from among the multiple candidate compatible devices as the migration target node of the instruction to be migrated based on the calculation result of the task migration benefit function, the method further includes: Bind the node identifier of the target node to the scheduling metadata structure instance corresponding to the instruction to be migrated, write a dedicated priority flag field into the scheduling metadata structure instance, mark the migration instruction as a migration priority task, and write a forced scheduling weight higher than the local high priority task into the scheduling metadata structure instance. The migration instruction and the scheduling metadata structure instance are written as atomic units to the high-priority task queue under the name of the migration target node through the high-priority task queue writing interface of the HarmonyOS distributed task scheduling framework. During the writing process, a timestamp and queue version number are added to maintain the consistency of the enqueue order. After the migration instruction is successfully enqueued, the scheduler is triggered to read the forced scheduling weight and issue a preemption signal to release the required scheduling window resources, so that the migration instruction is given priority in the scheduler of the migration target node in terms of computing cores and memory bandwidth, and during the execution process, it is continuously maintained at a higher scheduling level than the local high-priority task according to the forced scheduling weight until the task is completed.

[0012] Based on the above technical solutions, preferably, the step of selecting the target device from among the multiple candidate compatible devices as the migration target node of the instruction to be migrated, based on the calculation result of the task migration benefit function, specifically includes: Using the calculation result of the task migration benefit function corresponding to each candidate compatible device as input, the candidate compatible device set is cross-matched with the dynamic priority weight mapping table, and candidate compatible devices with priority weights lower than a set threshold are eliminated to obtain multiple first compatible devices; For multiple first compatible devices, the structural fit between the hardware capability vector of the first compatible device and the intermediate representation vector of the instruction to be migrated is recalculated based on the distributed structural matching function, and the first compatible devices with a fit lower than the preset compatibility threshold are removed to obtain multiple second compatible devices; The network transmission delay index and data dependency index of multiple second compatible devices are jointly ranked, and the dynamic priority weight is used as a weighting coefficient to generate a comprehensive ranking score. The second compatible device with the largest comprehensive ranking score is determined as the target device.

[0013] In a second aspect, the present invention provides a hardware resource dynamic instruction redirection apparatus, the apparatus being used to execute a hardware resource dynamic instruction redirection method as described in any of the above embodiments, the apparatus comprising an acquisition module, a processing module, and an output module, wherein: The device status information of all currently connected home terminal devices is collected through the HarmonyOS distributed soft bus. The device status information is filtered to retain multiple candidate idle devices that are in an idle state; The execution architecture requirements of the instructions to be migrated are adapted and matched with the underlying hardware architecture of the candidate idle devices, and candidate compatible devices that support the execution architecture requirements are retained among the candidate idle devices. A priority mechanism for migration instructions is constructed based on the preset HarmonyOS scheduling framework, and a dynamic priority weight is assigned to each instruction to be migrated. For each of the candidate compatible devices, the device performance evaluation function is invoked based on the dynamic priority weight to construct the task migration benefit function; Based on the calculation results of the task migration benefit function, the target device among the multiple candidate compatible devices is selected as the migration target node of the instruction to be migrated.

[0014] In a third aspect of the invention, an electronic device is provided, including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the preceding embodiments.

[0015] In a fourth aspect, the present invention provides a computer-readable storage medium storing instructions that, when executed, perform the method as described in any of the preceding claims.

[0016] In summary, one or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: 1. This invention introduces a full-link priority control mechanism for cross-device migration instructions based on the HarmonyOS native scheduling framework. It closely integrates device status acquisition, idle device screening, execution architecture adaptation, dynamic priority weight calculation, performance evaluation, and benefit function construction. During the target device selection process, priority weight is linked with multi-dimensional indicators such as structural adaptability, network latency, and data dependency. Thus, at the scheduling decision stage, migration instructions can be assigned a unique priority identifier higher than local high-priority tasks. Combined with forced scheduling weights, priority allocation and continuous guarantee of cross-node resources are achieved, enabling migration tasks to achieve low latency, high hit rate, and stable execution scheduling effects in multi-device heterogeneous hardware environments.

[0017] 2. By uniformly compiling the instructions to be migrated into an intermediate representation vector containing underlying runtime characteristics, and performing distributed structural adaptability calculations with the standardized hardware capability vectors of candidate idle devices, the instruction execution architecture requirements can be accurately matched in heterogeneous hardware environments. This allows for the selection of truly capable candidate compatible devices, avoiding migration failures or performance degradation due to architecture incompatibility.

[0018] 3. By adding a migration priority field to the HarmonyOS kernel task control block and calculating dynamic priority weights based on real-time level, data dependency, and global load distribution, cross-device migration instructions can obtain independent and dynamically adjustable priorities in the scheduling queue, thereby ensuring priority response for high real-time and high-dependency tasks in multi-device concurrent scenarios.

[0019] 4. Before dynamic priority weight calculation, architectural feature analysis and performance bottleneck analysis are introduced. The weighting coefficients of real-time level, data dependency degree and global load distribution are dynamically adjusted according to different bottleneck types to realize the linkage optimization of weight allocation with task execution architecture requirements and device performance status, thereby improving the pertinence of priority calculation and scheduling accuracy.

[0020] 5. By using dynamic priority weights as correction factors, the multi-dimensional performance indicators of candidate compatible devices are weighted and summarized, and a task migration benefit function is constructed in conjunction with the expected completion time. This allows for the simultaneous consideration of task urgency, device performance, and execution efficiency when selecting target devices, thereby improving the comprehensiveness and accuracy of migration decisions.

[0021] 6. After selecting the target device for migration, bind its identifier to the scheduling metadata structure instance of the migration instruction and write a dedicated priority tag and forced scheduling weight. Then, enqueue the instruction into the high-priority task queue and trigger preemptive scheduling. This ensures that the cross-device migration instruction receives continuous resource guarantees higher than local high-priority tasks during the execution phase, thereby ensuring low latency and high stability in task completion.

[0022] 7. By combining the results of the task migration benefit function with dynamic priority weights and secondary structure adaptability verification, as well as the joint ranking of network latency and data dependency, the target device with the best overall execution conditions can be accurately identified among the candidate compatible devices, ensuring that the migration decision achieves the optimal balance between performance, architecture matching and task characteristics. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a hardware resource dynamic instruction redirection method disclosed in an embodiment of the present invention; Figure 2 This is a schematic diagram of a hardware resource dynamic instruction redirection device disclosed in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention.

[0024] Explanation of reference numerals in the attached drawings: 201, acquisition module; 202, processing module; 203, output module; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0026] In the description of the embodiments of the present invention, words such as "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "for example" or "for instance" in the embodiments of the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of the present invention, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] HarmonyOS, Huawei's self-developed distributed operating system, relies on a microkernel architecture and a distributed soft bus to achieve seamless collaboration and resource sharing among various types of hardware devices. It supports cross-device task migration and multi-terminal deployment. However, its native scheduling framework is only optimized for local multi-task concurrency and lacks an independent priority determination and scheduling mechanism for cross-device migration instructions. It cannot guarantee the continuous and efficient execution of migration tasks in high-load competition environments in multi-device collaboration scenarios. Therefore, it is urgent to introduce a dedicated priority mechanism to improve the scheduling efficiency and execution stability of migration tasks between heterogeneous devices.

[0029] This embodiment discloses a method for dynamic instruction redirection of hardware resources, referring to... Figure 1 This includes the following steps S110-S160: The S110 collects device status information of all currently connected home terminal devices through the HarmonyOS distributed soft bus.

[0030] This invention discloses a hardware resource dynamic instruction redirection method applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablets, wearable devices, and PCs (Personal Computers), and can also be a backend server running a hardware resource dynamic instruction redirection method. The server can be implemented using a standalone server or a server cluster composed of multiple servers.

[0031] Communication connections are established with all currently connected home terminal devices through the HarmonyOS distributed soft bus. The distributed device management interface is called to obtain the device status information of each device in real time. The device status information includes multi-dimensional parameters such as device unique identifier, processor architecture type, current CPU core availability, GPU computing power utilization, remaining memory capacity, available storage space, network transmission latency, current task load level, and energy consumption status. Clock synchronization and data cache consistency control are performed during the collection process to ensure that when the device status information of the entire domain is aggregated to the source device, each parameter reflects the device operating status at the same sampling time. This provides an accurate, complete, and comparable data foundation for subsequent candidate idle device screening, architecture matching calculation, and migration priority allocation.

[0032] S120 filters the device status information and retains multiple candidate idle devices that are in an idle state.

[0033] After collecting status information of all home terminal devices via the HarmonyOS distributed soft bus, this device status information is passed as input to the candidate idle device screening module. This module first performs threshold checks on key operating parameters for each device, including CPU core availability, GPU computing power utilization, remaining memory capacity, and network transmission latency. Specifically, CPU core availability must be greater than a set idle threshold percentage, GPU computing power utilization must be lower than a set load threshold percentage, remaining memory capacity must not be less than the minimum memory capacity required for migration instruction execution, and network transmission latency must be lower than the maximum acceptable latency value of the distributed task scheduling framework. Through these multi-condition cross-checks, a preliminary set of devices that meet the idle criteria is generated.

[0034] After obtaining a set of devices that initially meet the criteria, the candidate idle device screening module calls the historical task load analysis submodule to retrieve the task load change curve and energy consumption fluctuation curve of each device in a recent period, and calculates its task load stability and energy consumption stability index. Devices that have experienced frequent load fluctuations or abnormal energy consumption in the historical operating cycle are eliminated to ensure that the screening results are not only idle at the current moment, but also have stable computing resource availability in the predicted migration execution cycle.

[0035] After completing the above elimination operation, the final set of retained devices is marked as the candidate idle device set. This set is then bound to the hardware capability vector and current device status information of each device, forming a candidate idle device description structure that includes device identifier, real-time operating parameters, historical load stability, energy consumption stability, and hardware capability vector. This candidate idle device description structure serves as the sole input data source for subsequent architecture matching calculations, ensuring a continuous and traceable technical link between the candidate idle device screening results and architecture adaptation calculations, dynamic priority weight allocation, and task migration benefit function construction. This maintains data consistency and decision-making coherence throughout the entire migration task scheduling process.

[0036] S130 adapts and matches the execution architecture requirements of the instructions to be migrated with the underlying hardware architecture of the candidate idle devices, and retains the candidate compatible devices that support the execution architecture requirements among multiple candidate idle devices.

[0037] In one possible implementation, the execution architecture requirements of the instructions to be migrated are adapted and matched with the underlying hardware architecture of the candidate idle devices, retaining candidate compatible devices that support the execution architecture requirements among multiple candidate idle devices. Specifically, this includes: converting the instructions to be migrated into a unified intermediate representation vector using Ark Compiler, the intermediate representation vector containing the underlying runtime features on which the execution of the instructions to be migrated depends; retrieving the underlying hardware abstraction identifier for each candidate idle device in real time to construct a standardized hardware capability vector; calculating the structural fit degree between the intermediate representation vector and the hardware capability vector using a distributed structural matching function; and determining candidate idle devices with a structural fit degree greater than a preset compatibility threshold as candidate compatible devices.

[0038] Specifically, the instructions to be migrated are executed through a unified compilation process on the source device side using Ark Compiler. First, the source code or bytecode of the instructions to be migrated is used as input to trigger front-end semantic analysis and instruction dependency resolution, generating an intermediate representation graph with control flow and data flow information. Then, the back-end analyzer performs target-independent feature extraction and quantization encoding on the intermediate representation graph, uniformly mapping the execution-related underlying runtime features to intermediate representation vectors. These intermediate representation vectors cover instruction set categories and extended subsets, vector register width and vectorization level, memory consistency model and atomic operation granularity, floating-point precision mode and rounding strategy, parallelism requirements and thread concurrency limits, cache locality level and working set size, and necessary cryptographic instruction families. Features include a random number source, a necessary set of acceleration operators and operator arithmetic precision, necessary runtime library symbols and version constraints, acceptable upper limits for network round-trip latency, and lower limits for input / output bandwidth. During the extraction process, discrete features are encoded using one-hot encoding, ordinal features are quantized using hierarchical quantization, and metric features are normalized using dimensionless quantization. A unified feature dictionary is used for numbering to ensure cross-device consistency. At the same time, a timestamp and compilation environment fingerprint are attached to the intermediate representation vector for subsequent tracing and consistency verification. If necessary, dynamic features with data correlation are sampled and backfilled after a very short warm-up phase using micro probes to ensure that the intermediate representation vector accurately reflects the actual runtime requirements of the instructions to be migrated.

[0039] For each candidate idle device, the underlying hardware abstraction identifier is retrieved locally via the hardware abstraction layer interface, and a hardware capability vector is constructed using standardized mapping rules. The hardware abstraction identifier returns parameters such as the device's processor architecture type, supported instruction sets and extended subsets, vector instruction support and vector register width, number of cores and currently available cores, base frequency and boost frequency, cache hierarchy and effective capacity, memory bandwidth and access latency, storage read / write bandwidth, network interface type and real-time round-trip latency statistics, GPU computing power and supported data type precision, operator support list and arithmetic precision of NPU or dedicated accelerator, available encryption modules and true random number capabilities, available runtime library set and version, current power consumption status and power efficiency per unit of computing power. These parameters are encoded with a feature dictionary consistent with the intermediate representation vector to generate a hardware capability vector, which includes a unique device identifier and a timestamp to represent a snapshot of the capability at the sampling time. Simultaneously, a sliding window smoothing is applied to the metric features that fluctuate with load to suppress instantaneous jitter, thereby ensuring that the hardware capability vector reflects both the device's static capability boundaries and its currently available capabilities.

[0040] The distributed structure matching function is used to calculate the structure fit in parallel on the source device for all candidate idle devices. The structural fit metric measures the compatibility between the intermediate representation vector and the hardware capability vector on the k-th fit item. The weights represent the relative importance of the k-th fit item to the instruction class to be migrated. The compatibility mapping function maps the compatibility relationship of the k-th feature pair to a comparable score between zero and one. The intermediate representation vector component represents the task-side requirement of the k-th fit item, and the hardware capability vector component represents the device-side supply of the k-th fit item. For strongly constrained discrete features such as architecture category and instruction set, the compatibility mapping function takes a value of one when there is a perfect match, a penalty value between zero and one when binary translation exists and performance degradation is controllable, and zero when not supported. For metrics such as vector register width and memory bandwidth, the compatibility mapping function uses the ratio of demand to supply. Saturation-type mapping approaches one when supply exceeds demand and decays proportionally to zero when supply is insufficient. For set-type features such as operator sets, the compatibility mapping function uses a coverage mapping based on the ratio of the intersection of the sets to the demand set. Key operators not covered trigger weight increases or directly set the compatibility mapping function to zero. For service-level features such as network latency and input / output bandwidth, the compatibility mapping function constructs a piecewise linear function based on the upper limit of demand and the measured supply value. Values ​​meeting the threshold are assigned higher scores, while values ​​exceeding the threshold decay proportionally. Weights are generated on the task side using a weighted coefficient generation method based on the execution architecture requirements and are normalized. On the device side, the compatibility mapping functions of each candidate idle device are computed in parallel and returned via a distributed soft bus. Source devices are aggregated to obtain the structural fit of each device. To reduce tail latency, structural fit calculation uses a device-side pre-computation table to accelerate invariant mapping, and source-side vectorized batch evaluation improves throughput. In case of cross-device network anomalies, the hardware capability vector of the most recent valid snapshot is used for evaluation and its timeliness is marked.

[0041] The retention of candidate compatible devices is determined by a combination of structural fit and migration safety strategies. A baseline is set based on a preset compatibility threshold according to the task category. At the same time, a passing condition must be met for strong constraint adaptation items. If the compatibility mapping function of any strong constraint adaptation item is zero, it is directly judged as incompatible. When the structural fit is greater than the preset compatibility threshold and all strong constraint adaptation items pass the passing condition, the corresponding candidate idle device is included in the candidate compatible device set. The hardware capability vector of the device, the corresponding intermediate representation vector, the structural fit value, and the evaluation timestamp are written into the candidate compatible device description structure for subsequent dynamic priority weight calculation and task migration benefit function construction. In extreme cases, if no device reaches the preset compatibility threshold, a dual-path degradation strategy is triggered. The first is to try to enable restricted binary translation or runtime operator replacement to improve the score of the compatibility mapping function and perform micro-benchmark verification in a safe sandbox. The second is to fall back to the source device for execution and record the incompatibility reasons to drive offline retraining of feature weights, thereby ensuring that the decision-making link still maintains determinism and interpretability in non-transferable scenarios.

[0042] S140 constructs a priority mechanism for migration instructions based on the preset HarmonyOS scheduling framework, assigning dynamic priority weights to each instruction to be migrated.

[0043] In one possible implementation, a priority mechanism for migration instructions is constructed based on a pre-defined HarmonyOS scheduling framework. Dynamic priority weights are assigned to each instruction to be migrated. Specifically, this includes: adding a migration priority field to the HarmonyOS kernel task control block, marking the instructions to be migrated as independent priority categories recognizable by the kernel scheduler; based on a priority allocation strategy, using the real-time performance level, data dependency, and global load distribution of the instruction to be migrated as input parameters, the real-time performance level is obtained by parsing the latency-sensitive feature field in the intermediate representation vector, the data dependency is determined by analyzing the size of the distributed cache consistency domain accessed by the migration instruction, and the global load distribution is determined by the device status information of candidate compatible devices; combining the real-time performance level, data dependency, and global load distribution according to a pre-defined weighting coefficient to form dynamic priority weights, writing these dynamic priority weights into the migration priority field, and using them as performance evaluation factors in the calculation of the task migration benefit function.

[0044] Specifically, the implementation of adding a migration priority field to the HarmonyOS kernel task control block involves extending the existing task control block with a single unsigned integer field to carry the fixed-point values ​​of dynamic priority weights. An independent priority category label is registered for migration instructions on the scheduling path, enabling the kernel scheduler to distinguish migration instructions from local ordinary tasks during ready queue orchestration and preemption determination. The field layout is upgraded to maintain existing alignment boundaries. The new field is zeroed by the distributed scheduling engine during task creation, written by the priority allocator after migration determination, and attached to the migration priority queue via the ready queue's category index. To ensure compatibility and real-time performance, the new field is atomically written and accompanied by a monotonically increasing timestamp for the scheduler to select the latest value. The scheduler prioritizes reading this field during time slice allocation and preemptibility determination, using it to determine the ranking of migration instructions and whether to trigger short-term preemption of local high-priority tasks.

[0045] The implementation method for calculating input parameters based on the priority allocation strategy involves parsing the intermediate representation vector of the instruction to be migrated to obtain the latency-sensitive feature field and deriving the real-time level. Data dependency is derived using the spatial scale and access intensity of the distributed cache consistency domain, and the overall load distribution is derived by aggregating the device status information of candidate compatible devices. The real-time level is calculated using the normalized margin of the deadline and end-to-end overhead. The task deadline is defined as the symbolic time constraint, and the sum of network transmission delay, remote execution delay, and context loading delay is defined as the end-to-end overhead. The formula for calculating the real-time level is given below.

[0046] in, This is a real-time performance level, used to characterize the urgency of the deadline for the instructions to be migrated. It is calculated based on the ratio of the difference between the task's time constraints and the expected end-to-end overhead. Deadline This indicates the latest time limit that the task must be completed; This indicates the network transmission latency from the source device to the target device for the migration command; This indicates the computation time required for the target device to execute the migration command; This indicates the time required to load the context (including register state, cached data, runtime dependencies, etc.). Total Expenses The larger the difference between the two values, the higher the real-time performance level; when the difference is less than zero, the real-time performance level is zero, indicating that the task cannot be completed within the deadline.

[0047] The real-time requirement level ranges from zero to one, with higher values ​​indicating greater urgency. Data dependency is scaled based on the size of the distributed cache consistency domain and the frequency of accesses per unit time. Let the consistency domain size be the spatial scale parameter, and the number of consistency domain accesses per unit time be the frequency parameter. A calibration constant is introduced to achieve dimensionless normalization. The formula for calculating data dependency is as follows:

[0048] in, The data dependency level is used to quantify the access dependency of the instructions to be migrated on the distributed cache consistency domain, reflecting the impact of data access on performance and correctness during the migration process. The spatial scale (e.g., number of bytes or pages) represents the consistency domain of the distributed cache, i.e., the size of the remote data region that needs to maintain consistency during the migration task execution; This represents the frequency of access to the consistency domain per unit time, i.e., the intensity of the migration task's access to the consistency domain during execution. The product of these two factors is expressed in the normalized coefficient. Adjusting the value reflects the sensitivity of the task to remote data consistency; a higher value indicates that the task is more sensitive to data consistency latency.

[0049] A higher degree of data dependency indicates a stronger sensitivity to the consistency of remotely shared data. Global load distribution uses a weighted aggregation of candidate compatible device utilization rates to reflect available resource reserves. Let the overall utilization rate of the i-th candidate compatible device be a device-side metric, and let its importance weight in the candidate set be a weight coefficient, with all weight coefficients summed to one. The calculation formula for global load distribution is given as follows:

[0050] in, For global load distribution, it is used to characterize the weighted average of the overall resource usage level of all candidate compatible devices. Indicates the first The overall utilization rate of candidate compatible devices can be calculated by integrating multiple indicators such as CPU core utilization, GPU computing power utilization, and memory utilization. Indicates the first The importance weight of each candidate compatible device in the global scheduling (which can be determined based on factors such as device performance level, task type compatibility, and historical execution stability), and all The sum is 1. The larger the global load distribution value, the higher the overall workload of the equipment.

[0051] A larger global load distribution indicates a higher overall level of activity. To improve robustness, all inputs are filtered using a sliding window to suppress jitter before computation, and timestamps are retained after computation for cross-module consistency verification.

[0052] The implementation method for combining real-time performance level, data dependency, and global load distribution to form dynamic priority weights involves using convex combination and online adaptive normalization of the weight coefficients. The result is then written into the migration priority field and integrated throughout the benefit evaluation process. The formula for calculating the dynamic priority weights is as follows:

[0053] and satisfy in, This is a priority weighting factor used to allocate the influence of real-time performance, data dependency, and global load distribution when calculating dynamic priority weights. All three are non-negative and their sum is 1. The weighting factor can be dynamically adjusted based on task type, execution architecture requirements, network conditions, etc. For example, it can be increased for latency-sensitive tasks. For tasks sensitive to data consistency, it can improve It can improve performance under high load conditions across the entire domain. Prioritize low-load devices.

[0054] The dynamic priority weight ranges from zero to one, with larger values ​​indicating higher scheduling priority. After being mapped to the migration priority field using a fixed-point mapping, the scheduler uses this value as the primary key when sorting the ready queue. Simultaneously, it serves as a performance evaluation factor in the task migration benefit function, participating in the target device scoring. The benefit function reflects the execution cost-effectiveness of the target device as the ratio of the comprehensive performance score to the time efficiency. The comprehensive performance score of the j-th candidate compatible device is defined as the output of the device performance evaluation function, and the estimated completion time of this device is defined as the end-to-end latency estimate. The formula for calculating the task migration benefit function is given below.

[0055] in, The dynamic priority weight is a crucial quantitative indicator for migration instructions during the scheduling phase. It is calculated by combining real-time performance level, data dependency, and global load distribution using weighted coefficients. A higher value indicates a higher priority for the migration instruction in the scheduling order and will directly influence the target device selection as a performance evaluation factor in the subsequent task migration benefit function calculation. The comprehensive performance score is the equipment performance evaluation function for the first... The output of the candidate compatible devices integrates multi-dimensional performance data, including real-time computing power, memory bandwidth, instruction set matching, network transmission latency, and energy efficiency. A weighted score is then calculated from these performance metrics. A higher value indicates better performance of the device when executing the migration instruction. The estimated completion time is the time when the migration instruction is in the specified number of iterations. The predicted total time from migration start to task completion on a candidate compatible device, including context transfer and loading time, execution time, and result return time. The smaller this value, the faster the device can complete the task. The task migration benefit function is used to measure the impact of scheduling migration instructions to the next task under the current dynamic priority weight. The overall cost-effectiveness index of the candidate compatible equipment is obtained by multiplying the dynamic priority weight and the equipment's comprehensive performance score by the estimated completion time. A higher value indicates that the equipment can complete the task in a shorter time while meeting the priority requirements, and has a significant performance advantage, thus making it more competitive in scheduling.

[0056] A larger task migration benefit function indicates a greater advantage in scheduling the migration instruction to the device under the current priority requirements. In this example, the real-time performance level can be set to 0.8, the data dependency level to 0.5, the global load distribution to 0.3, and the weighting coefficients to 0.5, 0.3, and 0.2. The dynamic priority weight is 0.71, calculated as 0.71 multiplied by 0.8, 0.3 multiplied by 0.5, and 0.2 multiplied by 0.7. If a candidate compatible device has a comprehensive performance score of 100 and an estimated completion time of 20 milliseconds, then the task migration benefit function for that device is 3.55, calculated as 0.71 multiplied by 100 and divided by 20. This results in a higher selection probability during the sorting phase and a forced scheduling weight mapping improvement when writing the migration priority field and the high-priority task queue.

[0057] In one possible implementation, before combining the real-time performance level, data dependency level, and global load distribution according to preset weighting coefficients to form dynamic priority weights, the method further includes: calling the architecture feature parsing module according to the execution architecture requirements to parse the computing resource types, instruction set complexity, parallelism requirements, and latency sensitivity levels involved in the execution architecture requirements, generating corresponding architecture feature vectors; comparing the architecture feature vectors with the global device resource capability matrix to determine the performance bottleneck types of the architecture features corresponding to the architecture feature vectors on different candidate compatible devices, including computing power bottlenecks, memory bandwidth bottlenecks, and network latency bottlenecks; and, according to the performance bottleneck types, assigning weights proportional to latency sensitivity levels to the weighting coefficients corresponding to the real-time performance level, weights proportional to cache consistency domain access frequency to the weighting coefficients corresponding to the data dependency level, and weights inversely proportional to the proportion of available computing power of the target device to the weighting coefficients corresponding to the global load distribution.

[0058] Specifically, after determining the intermediate representation vector of the instructions to be migrated, the architecture-related feature fields in the vector are extracted and input into the architecture feature parsing module. During the parsing process, the architecture feature parsing module first identifies the types of computing resources required by the instructions to be migrated, including general-purpose processing units (CPUs), graphics processing units (GPUs), neural network processing units (NPUs), cryptographic acceleration modules, etc. Secondly, it analyzes the complexity of the instruction set. The complexity measure includes not only the number of types of required instructions but also the proportion of special instruction extensions (such as SIMD extensions and cryptographic instruction sets) used and the degree of dependence on pipeline depth. Then, based on the parallelism requirements of the task, it analyzes the number of parallel threads and synchronization overhead required for the task at maximum performance, and combines this with the latency-sensitive feature fields in the intermediate representation vector to parse the latency sensitivity level. This level can be calculated by the ratio of the maximum tolerable response time of the task to the expected execution time of the task. The parsing results are used to generate an architecture feature vector in a numerical and normalized manner. Each component corresponds to a specific architecture feature parameter and is accompanied by a timestamp and task identifier for association and use in subsequent calculations.

[0059] The global device resource capability matrix is ​​composed of hardware capability vectors of all candidate compatible devices. Each row represents a candidate compatible device, and each column represents a specific architecture capability parameter, such as peak integer computing power, peak floating-point computing power, memory bandwidth limit, network interface latency, cache hierarchy structure parameters, etc. During the comparison process, each component of the architecture feature vector is compared with the value of the corresponding column in the resource capability matrix. When the demand value of an architecture feature component is higher than the supply value corresponding to a candidate compatible device, the performance limitation corresponding to that column is recorded as a performance bottleneck item. Performance bottleneck types include computing power bottleneck (insufficient computing resources), memory bandwidth bottleneck (limited data flow transmission), and network latency bottleneck (inter-node communication latency exceeds the limit). Each bottleneck type and its corresponding device identifier are recorded in the bottleneck analysis table to provide a basis for subsequent weighting coefficient allocation.

[0060] Based on the bottleneck analysis table, firstly, for the weighting coefficient corresponding to the real-time level, if the performance bottleneck type includes a network latency bottleneck and has a high latency sensitivity level, the proportion of this weighting coefficient is increased, making the real-time factor more prominent in the priority weight calculation for latency-sensitive tasks. Secondly, for the weighting coefficient corresponding to the data dependency level, if the performance bottleneck type includes a memory bandwidth bottleneck and has a high cache consistency domain access frequency, the value of this weighting coefficient is increased, making the data access characteristics have a more significant impact on the final priority weight. Finally, for the weighting coefficient corresponding to the global load distribution, if the performance bottleneck type includes a computing power bottleneck and the available computing power ratio of the target device is low, the reverse weight allocation ratio of this weighting coefficient is increased, thus favoring devices with a higher available computing power ratio when calculating priority weights. After the weighting coefficients are adjusted, they are normalized to ensure that the sum of the three coefficients is one, and they participate in the calculation of dynamic priority weights together with the real-time level, data dependency level, and global load distribution, realizing the dynamic linkage between the weight allocation strategy and the task execution architecture requirements and device performance bottleneck status.

[0061] S150, for each candidate compatible device, calls the device performance evaluation function based on dynamic priority weights to construct the task migration benefit function.

[0062] In one possible implementation, for each candidate compatible device, a task migration benefit function is constructed by calling a device performance evaluation function based on dynamic priority weights. Specifically, this includes: calling the device performance evaluation function, using the candidate compatible device's real-time computing power, memory bandwidth, instruction set matching degree, network transmission latency, and energy efficiency as input parameters. The real-time computing power is determined by the number of currently available CPU cores and the GPU computing unit utilization rate of the candidate compatible device; the memory bandwidth is determined by the ratio of the current throughput rate to the peak throughput rate of the candidate compatible device's memory controller; the instruction set matching degree is determined by the structural fit between the intermediate representation vector of the instruction to be migrated and the hardware capability vector of the candidate compatible device; the network transmission latency is determined by the real-time round-trip latency measurement between nodes provided by the HarmonyOS distributed soft bus; and the energy efficiency is determined by the unit computing power energy consumption ratio of the candidate compatible device. The dynamic priority weights are used as weight correction factors to weight and summarize the input parameters to obtain a comprehensive performance score. The task migration benefit function is constructed based on the inverse relationship between the comprehensive performance score and the expected execution time of the instruction to be migrated on the candidate compatible device.

[0063] Specifically, for each candidate compatible device, after the dynamic priority weights are calculated and written into the migration priority field, performance is evaluated using the candidate compatible device's real-time computing power, memory bandwidth, instruction set matching, network transmission latency, and energy efficiency as input parameters. The real-time computing power is calculated and normalized by combining the number of currently available CPU cores and their operating frequencies, the number of GPU computing units and their current utilization rate. The memory bandwidth is determined by the ratio of the current throughput rate of the candidate compatible device's memory controller to the device's nominal peak throughput rate. The instruction set matching is calculated by the structural fit between the intermediate representation vector of the instructions to be migrated and the hardware capability vector of the candidate compatible device; the structural fit formula is...

[0064] in, For structural adaptability, For the first The weight of the matching item, For the first Compatibility mapping function for item features The first intermediate representation vector of the task Item component, The first of the device hardware capability vectors The components are as follows: network transmission latency is obtained by real-time measurement of round-trip latency between nodes using the HarmonyOS distributed soft bus; energy efficiency is calculated by the reciprocal of the energy consumption ratio per unit computing power of candidate compatible devices, to reflect the energy consumption advantage of the device per unit performance.

[0065] Using dynamic priority weights as weighting adjustment factors, the five performance indicators are weighted and summed to obtain a comprehensive performance score. The calculation formula is as follows: in, For the first The overall performance score of the candidate compatible devices in Taiwan For dynamic priority weights, , , , , These are performance weight coefficients for real-time computing power, memory bandwidth, instruction set matching, network transmission latency, and energy efficiency, respectively, and all performance indicator values ​​are normalized values. and These are the reciprocals of the network latency and energy efficiency metrics, respectively, to ensure that the values ​​are positively correlated with performance.

[0066] A task migration benefit function is constructed based on the inverse relationship between the comprehensive performance score and the expected execution completion time of the instructions to be migrated on candidate compatible devices. The calculation formula is as follows: in, For the first The task migration benefit function value of the candidate compatible devices. The estimated completion time for the device to execute the migration instructions includes context transfer and loading time, task execution time, and result return time. The larger the benefit function value, the higher the migration benefit of the device under the current priority and performance conditions, and the more suitable it is as a migration target node.

[0067] S160, based on the calculation results of the task migration benefit function, select the target device from multiple candidate compatible devices as the migration target node of the instruction to be migrated.

[0068] In one possible implementation, based on the calculation result of the task migration benefit function, a target device among multiple candidate compatible devices is selected as the migration target node for the instruction to be migrated. Specifically, this includes: using the calculation result of the task migration benefit function corresponding to each candidate compatible device as input, cross-matching the set of candidate compatible devices with a dynamic priority weight mapping table, eliminating candidate compatible devices with priority weights lower than a set threshold, and obtaining multiple first compatible devices; recalculating the structural fit between the hardware capability vector of the first compatible device and the intermediate representation vector of the instruction to be migrated based on a distributed structural matching function, and removing first compatible devices with fits lower than a preset compatibility threshold, and obtaining multiple second compatible devices; jointly ranking the network transmission delay index and data dependency index of the multiple second compatible devices, using the dynamic priority weight as a weighting coefficient to generate a comprehensive ranking score, and determining the second compatible device with the largest comprehensive ranking score as the target device.

[0069] Specifically, the implementation method of cross-matching the candidate compatible device set with the dynamic priority weight mapping table, using the task migration benefit function calculation result corresponding to each candidate compatible device as input, is as follows: First, the task migration benefit function value of each candidate compatible device is... Compared to the dynamic priority weights calculated during the priority allocation phase A mapping relationship is established and stored in a dynamic priority weight mapping table. The scheduling engine reads the mapping data of all candidate compatible devices and assigns them to the set priority weight thresholds. Filter candidate compatible devices, all of which Devices that are directly eliminated will not be included in the subsequent screening process, thus ensuring that only those devices that have both high migration benefits and high scheduling priority under the current task scheduling requirements are retained, forming the first set of compatible devices.

[0070] The implementation method for recalculating the structural fit between the hardware capability vector and the intermediate representation vector of the instructions to be migrated for multiple first-compatible devices based on a distributed structural matching function is as follows: The structural fit has already been calculated for candidate idle devices during the preceding architecture matching stage. However, since device states may change during dynamic priority calculation and performance evaluation, a secondary adaptation verification is required for the first-compatible devices. Specifically, this involves calling the distributed structural matching function.

[0071] in, For structural adaptability, For the first Weights of fitting features For the first Compatibility mapping function for item features The first intermediate representation vector One portion, The first of the hardware capability vectors Each component. After calculation, the structural fit is compared with a preset compatibility threshold. Comparison, all The first compatible device is removed from the set, and the remaining devices form the second compatible device set, ensuring that the devices entering the next sorting step can still meet the execution architecture requirements in the latest state.

[0072] The implementation method for jointly ranking the network transmission latency and data dependency metrics of multiple second-compatible devices is as follows: First, obtain the current network transmission latency metric for each second-compatible device. (The inverse of the delay can be used to maintain a positive correlation between the value and performance) and data dependency metrics Then construct the comprehensive ranking score formula. in, For the first The overall ranking score of the second compatible device. and These are the weighting coefficients for network transmission latency and data dependency, respectively. Dynamic priority weight As a weighting amplification factor, it participates in the calculation, giving higher-priority devices a weight bias in the ranking. After the calculation is completed, all second-compatible devices are arranged from high to low according to their comprehensive ranking scores. The second-compatible device with the highest comprehensive ranking score is selected as the target device, and its device identifier is bound to the dynamic priority weight, task migration benefit function value, and structural adaptability. This is used for subsequent migration instruction-specific priority marking and high-priority queue enqueueing process, thereby ensuring that the selection of the target device forms a closed loop with the preceding priority calculation, architecture matching, and performance evaluation.

[0073] In one possible implementation, after selecting the target device from multiple candidate compatible devices as the migration target node for the instruction to be migrated based on the calculation result of the task migration benefit function, the method further includes: binding the node identifier of the migration target node with the scheduling metadata structure instance corresponding to the instruction to be migrated; writing a dedicated priority flag field into the scheduling metadata structure instance to mark the migration instruction as a migration priority task; and writing a forced scheduling weight higher than the local high-priority task into the scheduling metadata structure instance; writing the migration instruction and the scheduling metadata structure instance as atomic units into the high-priority task queue under the name of the migration target node through the high-priority task queue writing interface of the HarmonyOS distributed task scheduling framework, and attaching a timestamp and queue version number during the writing process to maintain the consistency of the enqueue order; after the migration instruction is successfully enqueued, triggering the scheduler to read the forced scheduling weight and issue a preemption signal to release the required scheduling window resources, so that the migration instruction is given priority in the scheduler of the migration target node in terms of computing cores and memory bandwidth, and continuously maintaining a scheduling level higher than the local high-priority task according to the forced scheduling weight during the execution process until the task is completed.

[0074] Specifically, when binding the target node identifier to the scheduling metadata structure instance corresponding to the migration instruction, a one-time binding transaction is generated in the scheduling metadata manager on the source device side. The target node identifier is written to the target node field of the scheduling metadata structure instance, and a version number is assigned to the scheduling metadata structure instance, with the write timestamp recorded. Subsequently, a dedicated priority flag field is created in the scheduling metadata structure instance and set as the migration priority task. At the same time, a forced scheduling weight field is created in the scheduling metadata structure instance and a weight value higher than that of local high-priority tasks is written to ensure that the scheduler prioritizes the migration instruction when performing ready queue orchestration and preemptibility judgment. To ensure data consistency, the binding transaction adopts an atomic write strategy supplemented by monotonically increasing version control and reentrancy protection. If the write verification fails, it rolls back to the previous valid version and retains an error snapshot for auditing. After binding is completed, the updated scheduling metadata structure instance is used as the sole input object for the queue write process, forming a continuous data link from selecting the target device to writing the flag and then generating the forced scheduling weight.

[0075] When enqueuing is performed through the high-priority task queue write interface of the HarmonyOS distributed task scheduling framework, an enqueue request is constructed using a scheduling metadata structure instance containing the migration target node identifier, a dedicated priority flag field, and a forced scheduling weight field, along with the migration instruction, as atomic units. The enqueue request is submitted to the high-priority task queue under the migration target node's name. During the submission process, the queue service automatically appends a timestamp and queue version number to maintain cross-device enqueue order consistency. The write operation employs a two-phase commit mechanism to ensure that the source device and the migration target node reach a consensus on the enqueue result. The pre-commit phase completes queue space reservation and sequence number allocation, while the commit phase completes pointer advancement and visibility publication. If either phase fails, the process rolls back to the most recent consistent snapshot based on the queue version number and re-applies for a sequence number until the write succeeds. To reduce concurrency conflicts, the queue write interface uses a multi-level ready linked list hierarchically based on forced scheduling weights on the high-priority task queue, ensuring that enqueue requests with higher forced scheduling weights obtain a higher ready position under the same timestamp conditions. After successful enqueueing, the queue service writes the final timestamp and queue version number back to the status field of the scheduling metadata structure instance, serving as the sole basis for subsequent scheduler reading and arbitration.

[0076] Once a migration instruction is successfully enqueued, the scheduler on the target node side reads the forced scheduling weight using the scheduling metadata structure instance as input. This forced scheduling weight is then mapped to two scheduling control parameters: preemption strength and minimum duration. Immediately, a preemption signal is sent to the local task queue to release the required scheduling window resources, allowing the migration instruction to be prioritized for allocation of computing cores and memory bandwidth during the ready phase. The preemption signal, issued by the scheduler core thread, carries the current timestamp and queue version number for consistency verification. It can interrupt tasks and place them in a safe suspension queue, or postpone tasks to the next scheduling cycle. If a real-time task's weight is below the forced scheduling weight, its allocation will be relinquished. The time slice and bandwidth quota are allocated; after the resource transfer is completed, the scheduler immediately allocates computing cores and memory bandwidth to the migration instruction and loads the execution context. During the execution process, it continuously maintains a scheduling level higher than the local high-priority task based on the forced scheduling weight. If the start-up delay or execution delay exceeds the threshold, the preemption intensity is increased and the resource occupancy ratio of the scheduling window is expanded until the task is completed. The results and performance indicators are written back to the scheduling metadata structure instance and the temporarily increased resource quota is released. At the same time, the final timestamp and version number are recorded to provide closed-loop feedback to the distributed task scheduling framework, realizing full-link priority guarantee from enqueuing to preemption to execution and recycling.

[0077] This embodiment also discloses a hardware resource dynamic instruction redirection device, referring to... Figure 2 The device includes an acquisition module 201, a processing module 202, and an output module 203. It is used to execute any of the above-described hardware resource dynamic instruction redirection methods, wherein: The acquisition module 201 is used to collect device status information of all currently connected home terminal devices through the HarmonyOS distributed soft bus.

[0078] The processing module 202 is used to filter the device status information and retain multiple candidate idle devices that are in an idle state.

[0079] The processing module 202 is used to adapt and match the execution architecture requirements of the instructions to be migrated with the underlying hardware architecture of the candidate idle devices, and retain the candidate compatible devices that support the execution architecture requirements among multiple candidate idle devices.

[0080] The processing module 202 is used to construct a priority mechanism for migration instructions based on the preset HarmonyOS scheduling framework, and to assign dynamic priority weights to each instruction to be migrated.

[0081] The processing module 202 is used to call the device performance evaluation function based on dynamic priority weights for each candidate compatible device and construct the task migration benefit function.

[0082] The output module 203 is used to select the target device from multiple candidate compatible devices as the migration target node of the instruction to be migrated based on the calculation result of the task migration benefit function.

[0083] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided above belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0084] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0085] The communication bus 302 is used to enable communication between these components.

[0086] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0087] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0088] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications. The GPU is responsible for rendering and drawing the content required for display. The modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0089] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. As a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface 303 module, and an application program for a hardware resource dynamic instruction redirection method.

[0090] exist Figure 3In the illustrated electronic device, the user interface 303 is primarily used to provide an input interface for the user and to acquire user input data. The processor 301 can be used to call an application program stored in the memory 305 that represents a dynamic instruction redirection method for hardware resources. When executed by one or more processors 301, this causes the electronic device to perform one or more methods as described in the above embodiments.

[0091] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to the present invention. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0092] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0093] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0094] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0095] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0096] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0097] The present invention also discloses a computer-readable storage medium storing instructions. When executed by one or more processors 301, these instructions cause an electronic device to perform one or more methods as described in the above embodiments.

[0098] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This invention is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for dynamic instruction redirection of hardware resources, characterized in that, The method includes: The device status information of all currently connected home terminal devices is collected through the HarmonyOS distributed soft bus. The device status information is filtered to retain multiple candidate idle devices that are in an idle state; The execution architecture requirements of the instructions to be migrated are adapted and matched with the underlying hardware architecture of the candidate idle devices, and candidate compatible devices that support the execution architecture requirements are retained among the candidate idle devices. A priority mechanism for migration instructions is constructed based on the preset HarmonyOS scheduling framework, and a dynamic priority weight is assigned to each instruction to be migrated. For each of the candidate compatible devices, the device performance evaluation function is invoked based on the dynamic priority weight to construct the task migration benefit function; Based on the calculation results of the task migration benefit function, the target device among the multiple candidate compatible devices is selected as the migration target node of the instruction to be migrated.

2. The hardware resource dynamic instruction redirection method according to claim 1, characterized in that, The process of adapting and matching the execution architecture requirements of the instructions to be migrated with the underlying hardware architecture of the candidate idle devices, and retaining candidate compatible devices that support the execution architecture requirements from among the candidate idle devices, specifically includes: The instructions to be migrated are converted into a unified intermediate representation vector by Ark Compiler. The intermediate representation vector contains the underlying runtime features on which the execution of the instructions to be migrated depends. For each of the candidate idle devices, the underlying hardware abstraction identifier is retrieved in real time to construct a standardized hardware capability vector; The structural fit between the intermediate representation vector and the hardware capability vector is calculated using a distributed structural matching function, wherein the distributed structural matching function is as follows: Where S represents the structural fit degree. The weight of the k-th fitting item. Let k be the compatibility mapping function between the k-th features. This is the intermediate representation vector corresponding to the k-th fitting item. This is the hardware capability vector corresponding to the kth adaptation item; Candidate idle devices whose structural adaptability is greater than a preset compatibility threshold are identified as candidate compatible devices.

3. The hardware resource dynamic instruction redirection method according to claim 1, characterized in that, The priority mechanism for migration instructions built based on the preset HarmonyOS scheduling framework assigns a dynamic priority weight to each instruction to be migrated, specifically including: A migration priority field is added to the HarmonyOS kernel task control block to mark the instructions to be migrated as an independent priority category that can be recognized by the kernel scheduler; Based on the priority allocation strategy, the real-time level, data dependency degree, and global load distribution of the instruction to be migrated are used as input parameters. The real-time level is obtained by parsing the latency-sensitive feature field in the intermediate representation vector. The data dependency degree is determined by analyzing the size of the distributed cache consistency domain to be accessed by the migration instruction. The global load distribution is determined by the device status information of the candidate compatible device. The real-time performance level, the degree of data dependence, and the global load distribution are combined according to a preset weighting coefficient to form a dynamic priority weight. The dynamic priority weight is written into the migration priority field and used as a performance evaluation factor in the calculation when constructing the task migration benefit function.

4. The hardware resource dynamic instruction redirection method according to claim 3, characterized in that, Before combining the real-time performance level, the data dependency degree, and the global load distribution according to a preset weighting coefficient to form a dynamic priority weight, the method further includes: According to the execution architecture requirements, the architecture feature parsing module is invoked to parse the computing resource types, computation instruction set complexity, parallelism requirements and latency sensitivity levels involved in the execution architecture requirements, and generate corresponding architecture feature vectors. The architecture feature vector is compared with the global device resource capability matrix to determine the performance bottleneck type of the architecture feature corresponding to the architecture feature vector on different candidate compatible devices, including computing power bottleneck, memory bandwidth bottleneck and network latency bottleneck. Based on the performance bottleneck type, the weighting coefficient corresponding to the real-time level is assigned a weight proportional to the latency sensitivity level; the weighting coefficient corresponding to the data dependency level is assigned a weight proportional to the cache consistency domain access frequency; and the weighting coefficient corresponding to the global load distribution is assigned a weight inversely proportional to the proportion of available computing power of the target device.

5. A method for dynamic instruction redirection of hardware resources according to claim 1, characterized in that, For each of the candidate compatible devices, the process of invoking the device performance evaluation function based on the dynamic priority weight and constructing the task migration benefit function specifically includes: The device performance evaluation function is invoked, with the real-time computing power index, memory bandwidth index, instruction set matching index, network transmission latency index, and energy efficiency index of the candidate compatible device as input parameters. The real-time computing power index is determined by the number of currently available CPU cores and the GPU computing unit utilization rate of the candidate compatible device. The memory bandwidth index is determined by the ratio of the current throughput rate to the peak throughput rate of the memory controller of the candidate compatible device. The instruction set matching index is determined by the structural adaptability between the intermediate representation vector of the instruction to be migrated and the hardware capability vector of the candidate compatible device. The network transmission latency index is determined by the real-time round-trip latency measurement value between nodes provided by the HarmonyOS distributed soft bus. The energy efficiency index is determined by the unit computing power energy consumption ratio of the candidate compatible device. The dynamic priority weight is used as a weight correction factor to weight and sum the input parameters of each item to obtain the comprehensive performance score. The task migration benefit function is constructed based on the inverse relationship between the comprehensive performance score and the estimated execution time of the instruction to be migrated on the candidate compatible device.

6. The hardware resource dynamic instruction redirection method according to claim 1, characterized in that, After selecting the target device from among the multiple candidate compatible devices as the migration target node for the instruction to be migrated based on the calculation result of the task migration benefit function, the method further includes: Bind the node identifier of the target node to the scheduling metadata structure instance corresponding to the instruction to be migrated, write a dedicated priority flag field into the scheduling metadata structure instance, mark the migration instruction as a migration priority task, and write a forced scheduling weight higher than the local high priority task into the scheduling metadata structure instance. The migration instruction and the scheduling metadata structure instance are written as atomic units to the high-priority task queue under the name of the migration target node through the high-priority task queue writing interface of the HarmonyOS distributed task scheduling framework. During the writing process, a timestamp and queue version number are added to maintain the consistency of the enqueue order. After the migration instruction is successfully enqueued, the scheduler is triggered to read the forced scheduling weight and issue a preemption signal to release the required scheduling window resources, so that the migration instruction is given priority in the scheduler of the migration target node in terms of computing cores and memory bandwidth, and during the execution process, it is continuously maintained at a higher scheduling level than the local high-priority task according to the forced scheduling weight until the task is completed.

7. A method for dynamic instruction redirection of hardware resources according to claim 1, characterized in that, The step of selecting a target device from among multiple candidate compatible devices as the migration target node for the instruction to be migrated, based on the calculation result of the task migration benefit function, specifically includes: Using the calculation result of the task migration benefit function corresponding to each candidate compatible device as input, the candidate compatible device set is cross-matched with the dynamic priority weight mapping table, and candidate compatible devices with priority weights lower than a set threshold are eliminated to obtain multiple first compatible devices; For multiple first compatible devices, the structural fit between the hardware capability vector of the first compatible device and the intermediate representation vector of the instruction to be migrated is recalculated based on the distributed structural matching function, and the first compatible devices with a fit lower than the preset compatibility threshold are removed to obtain multiple second compatible devices; The network transmission delay index and data dependency index of multiple second compatible devices are jointly ranked, and the dynamic priority weight is used as a weighting coefficient to generate a comprehensive ranking score. The second compatible device with the largest comprehensive ranking score is determined as the target device.

8. A hardware resource dynamic instruction redirection device, characterized in that, The apparatus is used to execute a hardware resource dynamic instruction redirection method as described in any one of claims 1-7, the apparatus comprising an acquisition module, a processing module, and an output module, wherein: The device status information of all currently connected home terminal devices is collected through the HarmonyOS distributed soft bus. The device status information is filtered to retain multiple candidate idle devices that are in an idle state; The execution architecture requirements of the instructions to be migrated are adapted and matched with the underlying hardware architecture of the candidate idle devices, and candidate compatible devices that support the execution architecture requirements are retained among the candidate idle devices. A priority mechanism for migration instructions is constructed based on the preset HarmonyOS scheduling framework, and a dynamic priority weight is assigned to each instruction to be migrated. For each of the candidate compatible devices, the device performance evaluation function is invoked based on the dynamic priority weight to construct the task migration benefit function; Based on the calculation results of the task migration benefit function, the target device among the multiple candidate compatible devices is selected as the migration target node of the instruction to be migrated.

9. An electronic device, characterized in that, The device includes a processor, a communication bus, a user interface, a network interface, and a memory. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The communication bus is used to enable communication between the components within the electronic device. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

Images