A Multimodal Resource-Aware Task Scheduling Method and System for Medical Computing Environments

Abstract

This invention relates to a multi-mode resource-aware task scheduling method and system for medical computing environments, belonging to the field of resource management and task scheduling technology. The method includes: obtaining the estimated execution time under different execution modes; calculating the resource return on investment (ROI) for each task; firstly, selecting qualified tasks from the waiting queue, and then selecting different combinations of scoring factors based on the priority level of each task; dynamically normalizing the scoring factors for each task; performing weighted fusion according to preset weights to obtain a comprehensive score for each task, and selecting the target task for the current round of scheduling based on the comprehensive score from high to low; and performing a reservation check before allocating resources to low-priority tasks. This invention overcomes the problems of heterogeneous task types, insufficient resource sensitivity, inconsistent timeliness requirements, and inflexible resource allocation, achieving higher resource utilization efficiency and stronger real-time performance assurance.

Description

Technical Field

[0001] This invention relates to a multi-mode resource-aware task scheduling method and system for medical computing environments, belonging to the field of computing resource management and task scheduling technology. Background Technology

[0002] In modern medical computing environments, such as medical image analysis and intelligent diagnostic reasoning, it is often necessary to process a large number of computationally intensive heterogeneous tasks simultaneously. Different types of medical computing tasks vary significantly in terms of algorithm structure, data scale, and memory access patterns, resulting in different sensitivities to multi-core CPU resources (i.e., parallel acceleration characteristics). That is, some tasks can significantly reduce their running time with an increase in the number of computing cores, while others are limited by memory bandwidth or algorithm bottlenecks, resulting in limited acceleration effects.

[0003] Meanwhile, the timeliness requirements of different medical services vary significantly, which directly determines their scheduling priority. For example, emergency image analysis tasks typically have strict completion deadlines, while routine screening tasks have relatively lenient deadlines. Therefore, ensuring the real-time performance of high-priority tasks while improving overall resource utilization has become a significant challenge for medical computing system scheduling.

[0004] However, existing scheduling methods are generally based on a single scheduling dimension (such as task length, arrival time, or deadline), lacking a comprehensive awareness of task parallel acceleration characteristics, resource sensitivity, and dynamic system load. This makes it difficult to meet the scheduling requirements of "balancing timeliness and efficiency" in medical computing environments. Therefore, a resource-aware task scheduling method is needed that can comprehensively consider task characteristics, execution modes, resource utilization efficiency, and system load status to balance timeliness and overall efficiency. Summary of the Invention

[0005] To address the problems of heterogeneous task types, insufficient resource sensitivity, inconsistent timeliness requirements, and inflexible resource allocation in medical computing task scheduling, this invention provides a multi-mode resource-aware task scheduling method and system for medical computing environments, in order to achieve higher resource utilization efficiency and stronger real-time assurance.

[0006] The present invention adopts the following technical solution:

[0007] A multi-modal resource-aware task scheduling method for medical computing environments includes:

[0008] Step 1: Obtain the estimated execution time of the pre-built performance profile under different execution modes;

[0009] The performance profile is constructed based on statistical analysis and clustering of the execution time of sample cases under different execution modes. For various medical computing tasks, based on their task type and complexity subtype, the average execution time under different execution modes (such as modes using different numbers of CPU cores) is obtained from the pre-constructed performance profile to characterize the typical runtime characteristics of the task under each execution mode.

[0010] Step 2: Based on the estimated execution time obtained in Step 1 for each execution mode, calculate the resource return on investment (ROI) for each task to quantify the efficiency of reducing the execution time of the task under different execution modes, so as to reflect the sensitivity of the task to changes in the number of CPU cores and provide a basis for subsequent resource matching decisions.

[0011] Step 3: First, select qualified tasks from the waiting queue. Then, according to the priority level of each task, select different combinations of scoring factors to call different scoring functions to score the tasks using multiple factors. The scoring factors include at least factors that reflect the urgency of the task, factors that reflect the efficiency of the task execution, and factors that reflect the degree of matching between the task and the system resource status. Different combinations of factors are used for tasks with different priorities.

[0012] Step 4: Perform dynamic normalization on the scoring factors of each task obtained in Step 3 to eliminate the dimensional differences between different scoring factors and ensure the fairness and stability of the weighted fusion process.

[0013] Step 5: The normalized scoring factors from Step 4 are weighted and fused according to preset weights to obtain the comprehensive score of each task. The target tasks for this round of scheduling are selected according to the comprehensive scores from high to low.

[0014] Step 6: Before allocating resources to low-priority tasks, a reservation check is performed to prevent low-priority tasks from occupying the last idle execution module of that task type, thus preventing high-priority tasks from executing in a timely manner. When the reservation condition is met, the scheduling of the low-priority task is postponed according to a preset reservation strategy, keeping it in the waiting queue, and a suitable task is re-selected for allocation, thereby ensuring the real-time requirements of high-priority tasks.

[0015] Preferably, in step 2, ,in This is the estimated execution time for the task in the minimum core count execution mode. This is the estimated execution time of the task in the highest core count execution mode. It is a very small positive number, used to prevent the denominator from being divided by zero;

[0016] This reflects the sensitivity of a task to multi-core acceleration. A value close to 1 indicates that the task has a significant parallel acceleration effect, while a value close to 0 indicates that the task has a performance bottleneck and should not be allocated too many CPU cores.

[0017] Preferably, in step 3, a qualified task is a task for which there is currently an idle execution module capable of processing its task type;

[0018] All qualified tasks are strictly stratified according to preset priorities, and high-priority tasks are always scheduled first. Low-priority tasks are only scored and sorted when there are no unprocessed high-priority tasks. No cross-level comparisons are made between different priority levels.

[0019] Preferably, for high-priority tasks, the scoring factors include: urgency factor. Efficiency factor and resource matching factor :

[0020] Emergency Factors The formula used to measure the time urgency of a task is as follows:

[0021]

[0022] in, Represents the remaining time for the task, indicating how much time is left before the deadline to complete the task; This indicates a preset minimum positive number, used to prevent division by zero in the denominator and ensure the stability of numerical calculations; The smaller, The larger the value, the more urgent the task. The calculation formula is:

[0023]

[0024] In order to provide a stable and fair evaluation benchmark, The estimated execution time of a task under a specified baseline execution mode. This is the current scheduling time; The task deadline is based on the task arrival time. The baseline estimated execution time and a easing factor related to task priority. Dynamically generated, the calculation formula is:

[0025]

[0026] To reflect the different timeliness requirements of tasks with different priorities, high-priority tasks... The range of values ​​is smaller, creating more pressing time constraints; while lower priority tasks... The range of values ​​is relatively large to provide more flexible schedulable time.

[0027] efficiency factor The efficiency of task execution is usually represented by the estimated execution time. The reciprocal of is used to increase the priority of shorter tasks, and the calculation formula is:

[0028]

[0029] Resource matching factor The formula for measuring the degree of match between the parallel acceleration characteristics of a task and the current resource status of the system is as follows:

[0030]

[0031] in It is determined by the average CPU core utilization rate of the system over a period of time.

[0032] Preferably, for low-priority tasks, the scoring factors include: efficiency factor. Fairness factor and resource matching factor Fairness factor This represents the cumulative waiting time of a task in the queue. It is used to increase the priority of tasks that have been waiting in the queue for a long time, in order to prevent tasks from starving. The calculation formula is:

[0033] .

[0034] Preferably, in step 4, dynamic minimum-maximum normalization is performed on each type of scoring factor for the current priority task. The normalization formula is as follows:

[0035]

[0036] in, Represents any original rating factor value (e.g.) ), and These are the minimum and maximum values ​​of this type of factor among all tasks to be evaluated in the current priority level;

[0037] Original rating factors , , , They were converted into normalized factors respectively. , , and .

[0038] Preferably, in step 5, for high-priority tasks, the overall score is:

[0039]

[0040] in, , , These are the preset weight coefficients for urgency factor, efficiency factor, and resource matching factor in high-priority tasks;

[0041] For low-priority tasks, the overall score is:

[0042]

[0043] in, , , The preset weight coefficients for efficiency factor, fairness factor, and resource matching factor are respectively assigned to low-priority tasks.

[0044] Preferably, in step 6, before assigning the task to the execution module, the scheduling module first performs a forward reservation check, with the following reservation check conditions:

[0045] The tasks to be assigned are of low priority;

[0046] The assignment will occupy the last available execution module for that task type;

[0047] There is at least one high-priority task of the same type in the waiting queue;

[0048] When all three conditions are met, the scheduling module suspends the allocation of the low-priority task, removes the low-priority task from the current set of qualified tasks, and then returns to step 5 to select the task with the second highest comprehensive score from the remaining tasks.

[0049] A multi-mode resource-aware task scheduling system for medical computing environments, used to implement the aforementioned multi-mode resource-aware task scheduling method for medical computing environments, includes:

[0050] The scheduling module, as the control unit, is responsible for executing the multi-mode resource-aware scheduling method;

[0051] The execution module is a task processing unit for various types of medical computing tasks. Different types of execution modules are used to process different types of medical computing tasks.

[0052] Performance profiles are used to store the estimated execution time of various tasks under different execution modes;

[0053] The CPU resource pool is used to manage the number of all available CPU cores in the system. When a task is ready to be executed, the resource pool allocates and locks a corresponding number of resources from the available cores according to the execution mode given by the scheduling module. After the task is completed, the occupied resources will be released back to the resource pool for use by subsequent tasks.

[0054] Preferably, a resource-state-based coordination mechanism is established between the scheduling module and the execution module to improve the flexibility of task scheduling and the efficiency of resource utilization in multiple execution modes.

[0055] When the execution module receives a task, it selects an appropriate execution mode for the task based on the preset decision logic and the current system resource status. The execution module's mode selection is only for making suggestions, and the final execution mode is subject to the verification result of the scheduling module.

[0056] When performing resource allocation, the scheduling module verifies the mode selection of the execution module. If the mode is unavailable under the current resource conditions, a mode degradation process will be triggered. The degradation process follows a predefined degradation order, which is arranged from high to low according to the number of CPU cores of the execution mode. The process will try each mode in the degradation order and select the first mode that meets the current available resources as the final execution mode. If all modes are unavailable, the execution of the task will be suspended and other qualified tasks will be scheduled first.

[0057] For any details not covered in this invention, please refer to the prior art.

[0058] The beneficial effects of this invention are as follows:

[0059] By introducing ROI metrics and resource matching scores, the parallel potential of tasks can be effectively matched with idle system resources, thereby optimizing the utilization efficiency of multi-core CPU resources.

[0060] By dynamically normalizing and weighting multiple factors such as urgency, efficiency, fairness, and resource utilization, the algorithm can achieve a better balance among multiple conflicting objectives such as real-time performance and efficiency.

[0061] By using a dynamic execution module reservation check mechanism, execution modules can be reserved in advance for upcoming high-priority tasks when resources are scarce, ensuring the scheduling priority of high-priority tasks and effectively avoiding priority inversion. Attached Figure Description

[0062] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0063] Figure 1This is a schematic diagram of the overall architecture of the present invention;

[0064] Figure 2 This is a flowchart of the multi-mode resource-aware task scheduling method for medical computing environments according to the present invention. Detailed Implementation

[0065] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. However, this is not the only description; all aspects not described in detail herein are based on conventional techniques in the art.

[0066] After receiving externally submitted medical computing tasks, the system adds them to a waiting queue and records their attributes, including task type, complexity subtype, priority, and deadline. The complexity subtype is clustered based on differences in task execution time. High-priority tasks are classified as emergency tasks, and low-priority tasks as routine tasks. The deadline is determined based on the task arrival time and estimated execution time according to preset rules. The scheduling module executes the scheduling method of this invention in a periodic triggering manner, selecting tasks to be executed and configuring resources according to the current system resource status and task attributes. The selected tasks run in the execution module according to a determined execution mode. After the task is completed, the occupied computing resources are released, and the system continues to process subsequent tasks.

[0067] Example 1

[0068] A multi-modal resource-aware task scheduling method for medical computing environments, such as Figure 2 As shown, it includes:

[0069] Step 1: Obtain the estimated execution time of the pre-built performance profile under different execution modes;

[0070] Based on historical execution data of medical computing tasks, performance profiles are pre-constructed through offline analysis to characterize the typical runtime characteristics of different task types under various execution modes. In each scheduling cycle, the scheduling module retrieves the estimated execution time of each task in the waiting queue from the performance profile under each execution mode, based on its task type and complexity subtype, for subsequent scheduling decisions.

[0071] Step 2: Based on the estimated execution time obtained in Step 1 for each execution mode, calculate the resource return on investment (ROI) for each task to quantify the efficiency of reducing the execution time of the task under different execution modes, so as to reflect the sensitivity of the task to changes in the number of CPU cores and provide a basis for subsequent resource matching decisions.

[0072] ,in This is the estimated execution time for the task in the minimum core count execution mode. This is the estimated execution time of the task in the highest core count execution mode. It is a very small positive number, used to prevent division by zero in the denominator; taking 4-core, 8-core, and 12-core execution modes as examples, at this time, This is the estimated execution time of the task in 4-core mode. This is the estimated execution time of the task in 12-core mode.

[0073] This reflects the sensitivity of a task to multi-core acceleration. A value close to 1 indicates that the task has a significant parallel acceleration effect, while a value close to 0 indicates that the task has a performance bottleneck and should not be allocated too many CPU cores.

[0074] Step 3: Multifactor scoring;

[0075] This step is the core of the scheduling decision-making process, and it uses a hierarchical, multi-factor scoring method to evaluate the scheduling priority of each task.

[0076] First, qualified tasks are selected from the waiting queue. Qualified tasks are those with available idle execution modules that can process their task type.

[0077] Then, based on the priority level of each task, different combinations of scoring factors are selected to call different scoring functions to score the tasks using multiple factors. The scoring factors include at least factors that reflect the urgency of the task, factors that reflect the efficiency of the task execution, and factors that reflect the degree of matching between the task and the system resource status. Different combinations of factors are used for tasks with different priorities.

[0078] All qualified tasks are strictly stratified according to preset priorities, and high-priority tasks are always scheduled first. Low-priority tasks are only scored and sorted when there are no unprocessed high-priority tasks. No cross-level comparisons are made between different priority levels.

[0079] In the scheduling process, this invention uses a differentiated combination of scoring factors based on task priority: high-priority tasks are measured by an urgency factor, while low-priority tasks, due to their more lenient deadlines and relatively lower timeliness requirements, are measured by a fairness factor to prevent low-priority tasks from being in a state of starvation for a long time.

[0080] For high-priority tasks, the scoring factors include: urgency factor. Efficiency factor and resource matching factor :

[0081] Emergency Factors The formula used to measure the time urgency of a task is as follows:

[0082]

[0083] in, Represents the remaining time for the task, indicating how much time is left before the deadline to complete the task; Represents a predefined minimal positive number (e.g.) This is used to prevent division by zero in the denominator and to ensure the stability of numerical calculations. The smaller, The larger the value, the more urgent the task. The calculation formula is:

[0084]

[0085] In order to provide a stable and fair evaluation benchmark, The estimated execution time of a task under a specified baseline execution mode. This is the current scheduling time; The task deadline is based on the task arrival time. The baseline estimated execution time and a easing factor related to task priority. Dynamically generated, the calculation formula is:

[0086]

[0087] To reflect the different timeliness requirements of tasks with different priorities, high-priority tasks... The range of values ​​is smaller, creating more pressing time constraints; while lower priority tasks... The range of values ​​is relatively large to provide more flexible schedulable time.

[0088] efficiency factor The efficiency of task execution is usually represented by the estimated execution time. The reciprocal of is used to increase the priority of shorter tasks, and the calculation formula is:

[0089]

[0090] Resource matching factor The formula for measuring the degree of match between the parallel acceleration characteristics of a task and the current resource status of the system is as follows:

[0091]

[0092] in It is determined by the average CPU core utilization rate of the system over a period of time.

[0093] For low-priority tasks, to avoid them remaining unprocessed for extended periods, the scoring factors include: efficiency factor. Fairness factor and resource matching factor Fairness factor This represents the cumulative waiting time of a task in the queue. It is used to increase the priority of tasks that have been waiting in the queue for a long time, in order to prevent tasks from starving. The calculation formula is:

[0094] .

[0095] Step 4: Dynamically normalize the result;

[0096] To prevent deviations in the weighted fusion results caused by differences in the numerical range (dimensions) of different scoring factors (such as urgency U and fairness F), the scheduling module performs dynamic normalization on the scoring factors of each task to eliminate the differences in the dimensions between different scoring factors and ensure the fairness and stability of the weighted fusion process.

[0097] For each scoring factor of the current priority task, dynamic min-max normalization is performed. The normalization formula is as follows:

[0098]

[0099] in, Represents any original rating factor value (e.g.) ), and These are the minimum and maximum values ​​of this type of factor among all tasks to be evaluated in the current priority level;

[0100] Through this step, the original rating factors , , , They were converted into normalized factors respectively. , , and They are all mapped to The interval ensures the fairness and effectiveness of subsequent weighted fusion.

[0101] Step 5: The normalized scoring factors from Step 4 are weighted and fused according to preset weights to obtain the comprehensive score of each task. The target tasks for this round of scheduling are selected according to the comprehensive scores from high to low.

[0102] For high-priority tasks, the scoring focuses on timeliness and efficiency, which can be seen as an application of the Earliest Deadline First (EDF) principle (embodied in...). The concepts of Shortest Processing Time First (SPT / WSPT) and Shortest Processing Time First (SPT / WSPT) are reflected in... The integration of ) and the introduction of resource matching degree ( This serves as an auxiliary decision-making factor. The overall score is:

[0103]

[0104] in, , , These are the preset weight coefficients for urgency factor, efficiency factor, and resource matching factor in high-priority tasks;

[0105] For low-priority tasks, the scoring focuses on efficiency and fairness, reflecting the Shortest Processing Time First (SPT / WSPT) principle (embodied in...). ) and aging mechanisms (manifested in The combination of ) also introduces resource matching degree ( To improve resource utilization. The overall score is:

[0106]

[0107] in, , , The preset weight coefficients for efficiency factor, fairness factor, and resource matching factor are respectively assigned to low-priority tasks.

[0108] The scheduling module ultimately selects the task with the highest score as the scheduling task for this round.

[0109] Step 6: Before allocating resources to low-priority tasks, a reservation check is performed to prevent low-priority tasks from occupying the last idle execution module of that task type, thus preventing high-priority tasks from executing in a timely manner. When the reservation condition is met, the scheduling of the low-priority task is postponed according to a preset reservation strategy, keeping it in the waiting queue, and a suitable task is re-selected for allocation, thereby ensuring the real-time requirements of high-priority tasks.

[0110] Before assigning tasks to the execution module, the scheduling module first performs a forward reservation check. The reservation check conditions are as follows:

[0111] The tasks to be assigned are of low priority;

[0112] The assignment will occupy the last available execution module for that task type;

[0113] There is at least one high-priority task of the same type in the waiting queue;

[0114] When all three conditions are met, the scheduling module suspends the allocation of the low-priority task, removes the low-priority task from the current set of qualified tasks, and then returns to step 5 to select the task with the second highest comprehensive score from the remaining tasks.

[0115] This step ensures the scheduling priority of high-priority tasks in resource-constrained scenarios, preventing priority inversion.

[0116] Example 2

[0117] A multi-mode resource-aware task scheduling system for medical computing environments is provided to implement the multi-mode resource-aware task scheduling method for medical computing environments described in Example 1, such as... Figure 1 As shown, the method of this invention can run in a medical computing system with a shared CPU resource pool. The method mainly includes the following functional modules, which work collaboratively through shared memory or inter-process communication mechanisms:

[0118] The scheduling module, acting as the control unit, is responsible for executing the multi-mode resource-aware scheduling method. Its main functions include:

[0119] 1. In each scheduling cycle, based on task attributes, estimated execution time, and resource consumption, execute the decision-making process of steps 1–6 to select the most suitable task from the waiting queue for processing;

[0120] 2. Perform dynamic execution module reservation checks to ensure that high-priority tasks still have available resources under high load conditions;

[0121] 3. Before executing a task, verify the required execution mode and provide approval or mode downgrade suggestions based on resource status;

[0122] 4. When resources are insufficient, a suboptimal execution mode is selected according to the degrade strategy of decreasing CPU core count to ensure continuous system operation.

[0123] The execution module is a task processing unit for various tasks. Different types of execution modules are used to handle different types of medical computing tasks. Each execution module has the following basic functions:

[0124] 1. Upon receiving a task, select an execution mode based on the current system resource status and task attributes;

[0125] 2. If the scheduling module proposes a mode degradation suggestion due to insufficient resources, the execution module can use the suboptimal execution mode to execute the task to ensure that the task starts execution as soon as possible;

[0126] 3. After the task is completed, return the occupied CPU cores to the resource pool and report the task's execution status and completion time.

[0127] Performance profiles are used to store the estimated execution time of various tasks under different execution modes. Their construction process is based on offline sampling and statistical analysis, and specifically includes the following steps:

[0128] Sample selection and benchmark measurement: Representative cases were selected from the medical dataset as samples. First, the serial execution time of each sample case in the benchmark environment was measured.

[0129] Complexity sub-type classification: Cluster analysis is performed based on the differences in the distribution of sequential execution times. For tasks with significant differences in execution time, they are clustered into different complexity sub-types according to the execution time distribution. For tasks with small differences in execution time, they are grouped into a single category.

[0130] Multi-execution mode performance testing and performance profile generation: The execution time of each case sample was measured under different execution modes. Finally, the average execution time of each complexity sub-category task under each execution mode was calculated to construct a performance profile.

[0131] This performance profile supports the scheduling algorithm, including:

[0132] Estimated execution time of the task;

[0133] A comprehensive evaluation of the urgency of the task and the efficiency of resource allocation;

[0134] Comparison of resource efficiency of different execution modes.

[0135] The CPU resource pool is used to manage the number of all available CPU cores in the system. When a task is ready to be executed, the resource pool allocates and locks a corresponding number of resources from the available cores according to the execution mode given by the scheduling module. After the task is completed, the occupied resources will be released back to the resource pool for use by subsequent tasks.

[0136] Example 3

[0137] A multi-mode resource-aware task scheduling system for medical computing environments, as described in Embodiment 2, differs in that a resource-state-based collaborative mechanism is established between the scheduling module and the execution module to improve the flexibility of task scheduling and resource utilization efficiency in multiple execution modes.

[0138] When the execution module receives a task, it selects an appropriate execution mode for the task based on the preset decision logic and the current system resource status. The execution module's mode selection is only for making suggestions, and the final execution mode is subject to the verification result of the scheduling module.

[0139] When performing resource allocation, the scheduling module verifies the mode selection of the execution module. If the mode is unavailable under the current resource conditions, a mode degradation process will be triggered. The degradation process follows a predefined degradation order, which is arranged from high to low according to the number of CPU cores of the execution mode. The process will try each mode in the degradation order and select the first mode that meets the current available resources as the final execution mode. If all modes are unavailable, the execution of the task will be suspended and other qualified tasks will be scheduled first.

[0140] Through the aforementioned collaborative mechanism, this invention can achieve the adaptation and dynamic adjustment of task execution modes, resulting in greater flexibility and resource utilization efficiency under multiple execution modes, while further enhancing the scheduling and guarantee capabilities of high-priority tasks under resource-constrained conditions.

[0141] Example 4

[0142] A multi-mode resource-aware task scheduling method for medical computing environments is presented, with further explanation of the technical solution of this invention in conjunction with specific scenarios. Based on Figure 1 The architecture shown is described, which includes a scheduling module, an execution module, a performance profiling module, and a CPU resource pool under unified management.

[0143] I. Simulation Environment Setup

[0144] In this embodiment, the simulation environment uses the following resource configuration:

[0145] 1. CPU resource pool

[0146] In this embodiment, a unified resource pool mechanism is adopted, providing a total of 32 CPU cores of computing resources for each execution module to dynamically apply for and use.

[0147] 2. Execution Module Configuration

[0148] This embodiment includes four independent execution modules, among which:

[0149] (1) Two LUNA16 task execution modules;

[0150] (2) Two BraTS task execution modules.

[0151] Each execution module supports three switchable execution modes: 12-core mode, 8-core mode, and 4-core mode.

[0152] 3. Scheduling Parameter Settings

[0153] The scheduling cycle is set to 1.0 second. The system introduces a priority mechanism, dividing tasks into two categories: high priority (emergency) and low priority (routine).

[0154] The corresponding multi-factor scoring weights are set as follows:

[0155] High priority weight: , , .

[0156] Low priority weight: , , .

[0157] High priority tasks The value range is set to [1.5, 3.0], for low-priority tasks. The value range is set to [5.0, 10.0].

[0158] 4.Performance portrait

[0159] In this embodiment, a task performance profile library was pre-built. Offline testing was conducted using 120 case samples from the LUNA16 dataset and 90 case samples from the BraTS2020 dataset. Based on the significant differences in execution time for the LUNA16 tasks, they were clustered into three complexity subcategories: fast, medium, and slow. The BraTS tasks showed smaller differences in execution time and were grouped into one category. Finally, the average execution time for each category under different modes was calculated and stored in the profile.

[0160] II. Initial State of the Scheduling Cycle

[0161] Assuming a new scheduling cycle begins at simulation time t = 1000.0s, the current simulation environment state is as follows:

[0162] 1. Resource availability

[0163] In the simulation environment, some cores are currently running other tasks, and the number of available cores is 8. The overall system load is: (32−8) / 32=75%.

[0164] 2. Execution Module Status

[0165] One LUNA16 execution module is idle, while all other modules are busy.

[0166] 3. Waiting queue status

[0167] At this time, the task waiting queue contains the following tasks to be scheduled, as shown in Table 1:

[0168] Table 1 Tasks to be scheduled

[0169]

[0170] The deadline for T1 is obtained as follows:

[0171] Deadline = 990 + (712.74 × 1.7) ≈ 2201 s.

[0172] III. Perform the scheduling process according to steps 1-6.

[0173] Step 1: Performance Profile Query

[0174] Based on the task type, subtype, and execution mode specified by the scheduling module, the system retrieves the estimated execution time of the task in 4-core, 8-core, and 12-core modes from the performance profile library, as shown in Table 2:

[0175] Table 2. Estimated execution schedules for 4-core, 8-core, and 12-core modes.

[0176]

[0177] Step 2: Quantization calculation of multi-core accelerated features

[0178] Using the ROI formula:

[0179]

[0180] Substituting the data, we get:

[0181] T1: ROI ≈ (1249.45 − 565.32) / 1249.45 ≈ 0.547;

[0182] T2: ROI ≈ (1686.99 − 753.55) / 1686.99 ≈ 0.553.

[0183] Step 3: Multifactor scoring

[0184] 3.1 Qualified Task Screening

[0185] The scheduling module first checks the system resource status and finds that there is currently one idle LUNA16 execution module.

[0186] Tasks T1 (LUNA16 type) and T2 (LUNA16 type) in the waiting queue both meet the resource matching conditions, therefore both T1 and T2 are qualified tasks.

[0187] 3.2 Strict Priority Hierarchy

[0188] The scheduling module scans the set of qualified tasks and identifies a high-priority task T1. Based on the strict hierarchical strategy of this invention, the high-priority level is locked for processing. Therefore, only tasks (T1) within this level are subsequently scored; low-priority tasks (T2) do not participate in this round of scoring calculations.

[0189] 3.3 Multifactor scoring calculation

[0190] For task T1 within the current priority level, the system calls the combination of higher priority scoring factors ( Perform the calculation:

[0191] (1) Urgency factor

[0192]

[0193]

[0194]

[0195] because Therefore Values .

[0196] (2) Efficiency factor

[0197]

[0198] (3) Resource matching degree

[0199]

[0200] Step 4: Dynamic normalization processing

[0201] The system performs min-max normalization on all candidate tasks in the current priority level (high priority). Since there is only one candidate task T1 in this level, the normalized scores of all original factors are 1.0, i.e. , , .

[0202] Step 5: Weighted Fusion and Task Selection

[0203] The system presets weights based on high priority ( Calculate the final overall score for T1:

[0204]

[0205]

[0206] The system selects T1 as the target task for this round of scheduling.

[0207] Step 6: Reserved checks for dynamic execution modules

[0208] Before officially allocating resources, the system performs a reservation logic check on the target task T1. Since the target task T1 is a high-priority task, the dynamic reservation mechanism is not triggered, and the system directly enters the subsequent resource allocation process.

[0209] IV. Execution Mode Selection and Downgrade Negotiation

[0210] 1. Initial Mode Application

[0211] Considering the high priority of T1 and its tight deadline, the idle LUNA16 execution module requests the scheduling module to run the task in 12-core mode.

[0212] 2. Resource verification and mode downgrade

[0213] The scheduling module verifies the application and makes the following judgments:

[0214] The current number of available cores is 8, which is insufficient to meet the requirement of running 12 cores, therefore the initial application was rejected.

[0215] The system then automatically attempts the suboptimal mode, i.e., the 8-core mode, according to the preset degradation sequence list (12 cores → 8 cores → 4 cores).

[0216] After rechecking, the current resources can meet the 8-core requirement, therefore the task is approved to be executed in 8-core mode.

[0217] V. Scheduling Results

[0218] Task T1 was assigned to an idle LUNA16 execution module and started execution in 8-core mode. The number of available cores in the resource pool was reduced from 8 cores to 0 cores.

[0219] Task T2 remains in the waiting queue and will enter the subsequent scheduling cycle after the resources are released.

[0220] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A multi-mode resource-aware task scheduling method for medical computing environments, characterized in that, include: Step 1: Obtain the estimated execution time of the pre-built performance profile under different execution modes; Step 2: Based on the estimated execution time obtained in Step 1 for each execution mode, calculate the efficiency of reducing the execution time of the task under different execution modes, i.e., the resource return rate (ROI) for each task. Step 3: First, select qualified tasks from the waiting queue. Then, based on the priority level of each task, select different combinations of scoring factors to call different scoring functions to perform multi-factor scoring on the task. Step 4: Perform dynamic normalization on the scoring factors of each task obtained in Step 3. Step 5: The normalized scoring factors from Step 4 are weighted and fused according to preset weights to obtain the comprehensive score of each task. The target tasks for this round of scheduling are selected according to the comprehensive scores from high to low. Step 6: Before allocating resources to low-priority tasks, perform a reservation check to prevent low-priority tasks from occupying the last idle execution module of the task type, thus preventing high-priority tasks from being executed in a timely manner. In step 3, a qualified task is a task for which there is an available idle execution module that can process its task type; All qualified tasks are strictly stratified according to preset priorities, and high-priority tasks are always scheduled first. Low-priority tasks are scored and sorted only when there are no unprocessed high-priority tasks. No cross-level comparisons are made between different priority levels. For high-priority tasks, the scoring factors include: urgency factor. Efficiency factor and resource matching factor : Emergency Factors The formula used to measure the time urgency of a task is as follows: in, Represents the remaining time for the task, indicating how much time is left before the deadline to complete the task; This indicates a preset minimum positive number, used to prevent division by zero in the denominator and ensure the stability of numerical calculations; The smaller, The larger the value, the more urgent the task. The calculation formula is: in, The estimated execution time of a task under a specified baseline execution mode. This is the current scheduling time; The task deadline is based on the task arrival time. The baseline estimated execution time and a easing factor related to task priority. Dynamically generated, the calculation formula is: efficiency factor This represents the efficiency of task execution and the estimated execution time. The reciprocal of is used to increase the priority of shorter tasks, and the calculation formula is: Resource matching factor The formula for measuring the degree of match between the parallel acceleration characteristics of a task and the current resource status of the system is as follows: in It is determined by the average CPU core utilization rate of the system over a period of time; For low-priority tasks, the scoring factors include: efficiency factor. Fairness factor and resource matching factor Fairness factor This represents the cumulative waiting time of a task in the queue. It is used to increase the priority of tasks that have been waiting in the queue for a long time, in order to prevent tasks from starving. The calculation formula is: 。 2. The multi-mode resource-aware task scheduling method for medical computing environments according to claim 1, characterized in that, In step 2, ,in This is the estimated execution time for the task in the minimum core count execution mode. This is the estimated execution time of the task in the highest core count execution mode. It is a very small positive number, used to prevent the denominator from being divided by zero; This reflects the sensitivity of a task to multi-core acceleration. A value close to 1 indicates that the task has a significant parallel acceleration effect, while a value close to 0 indicates that the task has a performance bottleneck and should not be allocated too many CPU cores.

3. The multi-mode resource-aware task scheduling method for medical computing environments according to claim 2, characterized in that, In step 4, dynamic minimum-maximum normalization is performed on each type of scoring factor for the current priority task. The normalization formula is as follows: in, Represents any original rating factor value. and These are the minimum and maximum values ​​of this type of factor among all tasks to be evaluated in the current priority level; Original rating factors , , , They were converted into normalized factors respectively. , , and .

4. The multi-mode resource-aware task scheduling method for medical computing environments according to claim 3, characterized in that, In step 5, for high-priority tasks, the overall score is: in, , , These are the preset weight coefficients for urgency factor, efficiency factor, and resource matching factor in high-priority tasks; For low-priority tasks, the overall score is: in, , , The preset weight coefficients for efficiency factor, fairness factor, and resource matching factor are respectively assigned to low-priority tasks.

5. The multi-mode resource-aware task scheduling method for medical computing environments according to claim 4, characterized in that, In step 6, before assigning the tasks to the execution module, the scheduling module first performs a forward reservation check. The reservation check conditions are as follows: The tasks to be assigned are of low priority; The allocation will occupy the last available execution module for that task type; There is at least one high-priority task of the same type in the waiting queue; When all three conditions are met, the scheduling module suspends the allocation of the low-priority task, removes the low-priority task from the current set of qualified tasks, and then returns to step 5 to select the task with the second highest comprehensive score from the remaining tasks.

6. A multi-mode resource-aware task scheduling system for medical computing environments, characterized in that, The method for implementing the multi-mode resource-aware task scheduling method for medical computing environments according to any one of claims 1-5 includes: The scheduling module, as the control unit, is responsible for executing the multi-mode resource-aware scheduling method; The execution module is a task processing unit for various types of medical computing tasks. Different types of execution modules are used to process different types of medical computing tasks. Performance profiles are used to store the estimated execution time of various tasks under different execution modes; The CPU resource pool is used to manage the number of all available CPU cores in the system. When a task is ready to be executed, the resource pool allocates and locks a corresponding number of resources from the available cores according to the execution mode given by the scheduling module. After the task is completed, the occupied resources will be released back to the resource pool for use by subsequent tasks.

7. The multi-mode resource-aware task scheduling system for medical computing environments according to claim 6, characterized in that, A resource-state-based coordination mechanism is established between the scheduling module and the execution module to improve the flexibility of task scheduling and the efficiency of resource utilization in multiple execution modes. When the execution module receives a task, it selects an appropriate execution mode for the task based on the preset decision logic and the current system resource status. The execution module's mode selection is only for making suggestions, and the final execution mode is subject to the verification result of the scheduling module. When the scheduling module performs resource allocation, it verifies the mode selection of the execution module. When the mode is unavailable under the current resource conditions, it will trigger the mode degradation process. The degradation process is carried out according to a predefined degradation order, which is arranged from high to low according to the number of CPU cores of the execution mode. The process will attempt each mode in the degrading order, selecting the first mode that satisfies the currently available resources as the final execution mode; if all modes are unavailable, the task will be suspended and other qualified tasks will be scheduled first.

Images