Supercomputing task priority dynamic scheduling method and system adapting to green power fluctuation

Abstract

The invention provides a supercomputing task priority dynamic scheduling method and system adapting to green power fluctuation. The method comprises the following steps: acquiring a power supply and demand state of a supercomputing system in real time; when it is detected that power supply is insufficient, the attributes of the current supercomputing tasks are recognized and classified, and the priorities of the supercomputing tasks are set; and according to the power supply and demand states and the priorities of the supercomputing tasks, intelligently scheduling the operation sequence of the supercomputing tasks. The priorities of the super-computing tasks are set according to the super-computing task attributes, when power supply is insufficient, the super-computing tasks with the high priorities are preferentially operated, the super-computing tasks with the low priorities are paused, task execution strategies are dynamically scheduled, the utilization efficiency of green power is remarkably improved, the overall energy consumption of the system is reduced, and the system performance is improved. And smooth execution of key tasks is guaranteed under the condition that electric power is limited, so that energy adaptability and operation toughness of the supercomputing system are enhanced, and the supercomputing system is promoted to continuously evolve towards green, efficient and intelligent directions.

Description

Technical Field

[0001] This application relates to the field of computer system resource management technology, and in particular to a method, system, device, computer-readable medium, and computer program product for dynamic scheduling of supercomputing task priorities to adapt to green power fluctuations. Background Technology

[0002] With the continuous growth in demand for high-performance computing (HPC) capabilities in fields such as scientific research, industrial simulation, climate modeling, and artificial intelligence, supercomputers (or "supercomputers") are becoming increasingly important as the core computing power platform supporting these complex tasks. However, supercomputing systems typically consume enormous amounts of energy during operation, and energy costs and efficiency issues have gradually become one of the key factors restricting their sustainable development.

[0003] Green electricity, such as renewable energy sources like solar and wind power, possesses inherent advantages such as being clean, low-carbon, and renewable. It can effectively reduce the carbon emission intensity of supercomputing systems, alleviate environmental pressure, and improve the sustainability of energy use. Therefore, green electricity has significant strategic importance in promoting the green and low-carbon transformation of supercomputing systems. However, the supply of green electricity is significantly affected by natural conditions, exhibiting typical intermittency, volatility, and unpredictability. Its power output is easily disturbed by factors such as weather, seasons, and diurnal variations, making it difficult to achieve continuous and stable power supply, posing a challenge to the continuous operation of high-energy-consuming systems such as supercomputing.

[0004] It is worth noting that supercomputing tasks generally have low real-time requirements and good operational flexibility. Many tasks support delayed execution, reduced frequency operation, phased pauses, or interrupt recovery, demonstrating strong controllability and fault tolerance. Therefore, from the perspective of task characteristics, there is a natural match between the volatility of green electricity and the operational flexibility of supercomputing tasks. However, current supercomputing resource management systems are generally based on the assumption of a fixed power supply, lacking the ability to perceive and respond to the volatility characteristics of green electricity. Most operational strategies still primarily rely on resource quantity and task queuing order, failing to fully consider dynamic changes in power supply, which can easily lead to the following problems:

[0005] 1. High-priority tasks are delayed when green electricity is scarce;

[0006] 2. Blindly running new tasks when the power supply is tight may cause power outages or energy overload.

[0007] 3. Lack of fine-grained management of interruptible and frequency-reduced tasks makes it difficult to release redundant power consumption;

[0008] 4. Disorderly interruption of critical tasks during sudden power shortages affects computing reliability and task completion rate.

[0009] Therefore, how to reduce the power consumption of supercomputers and improve their operating efficiency and power utilization is a technical problem that needs to be solved. Summary of the Invention

[0010] This application provides a method, system, device, computer-readable medium, and computer program product for dynamic scheduling of supercomputing task priorities to adapt to green power fluctuations. It aims to solve the problem that existing supercomputing resource operation systems lack perception and response mechanisms when facing green power fluctuations, resulting in excessive power consumption, low utilization, and low system operating efficiency.

[0011] To achieve the above technical effects, one aspect of this application provides a method for dynamic scheduling of supercomputing task priorities to adapt to green power fluctuations, including: real-time acquisition of the power supply and demand status of the supercomputing system;

[0012] When insufficient power supply is detected, the attributes of the current supercomputing tasks are identified and classified, and the priorities of the supercomputing tasks are set.

[0013] Based on the power supply and demand status and the priority of the supercomputing tasks, the execution order of the supercomputing tasks is intelligently scheduled.

[0014] According to a preferred embodiment of the present invention, the real-time acquisition of the power supply and demand status of the supercomputing system further includes:

[0015] Real-time acquisition of power supply and energy consumption of the supercomputing system;

[0016] By comparing the power supply capacity with the energy consumption of the supercomputing system, it can be determined whether the current power supply and demand status should be maintained.

[0017] According to a preferred embodiment of the present invention, when insufficient power supply is detected, the step of identifying and classifying the attributes of the current supercomputing task and setting the priority of the supercomputing task further includes:

[0018] Identify the attributes of the current supercomputing task, including: frequency sensitivity, ability to resume computation from breakpoints, interruptibility, and runtime delayability;

[0019] Based on the aforementioned attributes, each supercomputing task is classified and its importance is determined. The classified supercomputing tasks are then prioritized.

[0020] According to a preferred embodiment of the present invention, the step of classifying each supercomputing task according to the attribute and determining its importance, and then prioritizing the classified supercomputing tasks, further includes:

[0021] The supercomputing tasks are divided into two main categories: those currently running and those yet to be run.

[0022] Based on three attribute dimensions—whether the frequency can be reduced, whether it can be interrupted, and whether it can be recovered—the running supercomputing tasks are further divided into five categories, and based on the attribute dimension—whether the supercomputing tasks to be run—the tasks to be run are further divided into two categories.

[0023] Different priorities are assigned to each category based on the importance of the supercomputing task.

[0024] According to a preferred embodiment of the present invention, the step of intelligently scheduling the supercomputing task execution order based on the power supply and demand status and the importance of the supercomputing task further includes:

[0025] Identify whether there are any supercomputing tasks waiting to be run, and if so, run them in order of priority.

[0026] Identify the current power supply and demand status. If supply exceeds demand, shut down idle components. If supply is less than demand, run currently running supercomputing tasks in descending order of priority.

[0027] Supercomputing tasks that are running will be interrupted or reduced in frequency in order of priority from low to high until supply and demand are balanced.

[0028] According to a preferred embodiment of the present invention, after intelligently scheduling the execution order of supercomputing tasks, the method further includes:

[0029] If the power supply is still unable to maintain the current operation status of the supercomputing task after the intelligent scheduling of the supercomputing task execution order, an alarm will be triggered and the management personnel will be notified to start the emergency power supply.

[0030] Another aspect of this application provides a dynamic scheduling system for supercomputing tasks that adapts to fluctuations in green electricity demand, comprising:

[0031] Status acquisition module: used to acquire the power supply and demand status of the supercomputing system in real time;

[0032] Task classification module: When insufficient power supply is detected, it identifies the attributes of the current supercomputing tasks, classifies them, and sets the priorities of the supercomputing tasks.

[0033] The task scheduling module is used to intelligently schedule the execution order of supercomputing tasks based on the power supply and demand status and the priority of the supercomputing tasks.

[0034] Another aspect of this application provides a supercomputing task priority dynamic scheduling device adapted to green power fluctuations, the device comprising:

[0035] At least one processor; and a memory communicatively connected to said at least one processor; wherein,

[0036] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0037] In another aspect, this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the above-described method.

[0038] In another aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described above.

[0039] The solution provided in this application has the following beneficial effects:

[0040] This application sets the priority of supercomputing tasks based on their attributes. When power supply is insufficient, high-priority supercomputing tasks are run first while low-priority supercomputing tasks are suspended. This dynamic scheduling strategy significantly improves the utilization efficiency of green electricity, reduces the overall energy consumption of the system, and ensures the smooth execution of critical tasks under power constraints. This enhances the energy adaptability and operational resilience of the supercomputing system and promotes its continuous evolution towards green, efficient, and intelligent directions. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0043] Figure 1 A flowchart illustrating a dynamic scheduling method for supercomputing tasks that adapts to green power fluctuations, provided as an embodiment of this application;

[0044] Figure 2 A flowchart illustrating a dynamic scheduling method for supercomputing task priorities adapted to green power fluctuations, provided as an embodiment of this application;

[0045] Figure 3 A schematic diagram of a supercomputing task priority dynamic scheduling system adapted to green power fluctuations is provided in one embodiment of this application;

[0046] Figure 4This is a schematic diagram of the structure of a device suitable for implementing the solutions in the embodiments of this application.

[0047] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0050] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0051] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer program instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0052] In practical scenarios, the execution entity of this method can be a user device, or a device formed by integrating a user device and a network device through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0053] This invention proposes a dynamic scheduling method for supercomputing tasks that adapts to fluctuations in green electricity supply, using green renewable energy sources such as solar and wind power as examples for illustration. Figure 1 This is a flowchart illustrating a dynamic scheduling method for supercomputing tasks that adapts to green power fluctuations, provided in one embodiment of this application. Figure 2 A flowchart illustrating a dynamic scheduling method for supercomputing tasks based on power fluctuations, as provided in an embodiment of this application, is shown below. Figure 1 and Figure 2 As shown, the method includes at least the following processing steps:

[0054] Step S101: Obtain the power supply and demand status of the supercomputing system in real time.

[0055] Specifically, the system acquires real-time power supply and supercomputing system energy consumption. It calculates the overall power consumption level of the supercomputing cluster, encompassing the total energy consumption of multiple subsystems, including computing nodes, communication networks, and cooling systems. The actual output power of green electricity (such as photovoltaic and wind power) can be obtained through smart grid interfaces or energy management systems, in kilowatts (kW). 2. The system calculates the current total power consumption of the supercomputing cluster: It statistically analyzes the real-time energy consumption of all computing nodes, storage systems, and auxiliary subsystems within the platform, also in kilowatts (kW).

[0056] To avoid frequent task execution triggered by minor fluctuations in power data, the system sets a power consumption redundancy safety threshold to absorb short-term supply-demand discrepancies. The system compares the power supply output with the supercomputing system's energy consumption to determine whether to maintain the current power supply-demand balance.

[0057] When the supply capacity of green electricity is significantly higher than the current total power consumption of the system and there is a certain safety redundancy, the system judges that the current power supply is sufficient to maintain the current task operation status.

[0058] If the supply capacity of green electricity is lower than the total power consumption required by the system (i.e. there is a significant power shortage), the system determines that green electricity is insufficient and immediately initiates the task control process, including restricting the operation of new tasks and implementing energy-saving control for currently running tasks.

[0059] The specific judgment criteria are as follows:

[0060] If the green power supply is greater than or equal to the current total power consumption × (1 + safety redundancy coefficient), and the redundancy coefficient is 10%, then the green power is considered sufficient, and the system maintains its current task operation status without adjustment.

[0061] If the green power supply is less than the current total power consumption × (1 − redundancy coefficient), then the green power supply is determined to be insufficient, and the system immediately activates the task energy-saving control strategy.

[0062] This judgment mechanism can effectively avoid frequent operation switching caused by short-term power fluctuations, ensure the system's stable perception and reasonable response to changes in power status, and provide a basis for decision-making for subsequent operation strategies.

[0063] Step S102: When insufficient power supply is detected, identify and classify the attributes of the current supercomputing task, and set the priority of the supercomputing task.

[0064] Specifically, the supercomputing tasks are first divided into two main categories: those currently running and those awaiting execution. Furthermore, the attributes of these tasks are categorized into four types: frequency sensitivity, ability to resume computation after a breakpoint, interruptibility, and operational delayability.

[0065] 1. Frequency Sensitivity (performance response to CPU frequency drops): High-performance computing tasks typically rely on fixed computational programs, requiring repeated simulations or experiments using multiple sets of parameter files. Based on this characteristic, the system pre-evaluates commonly used computational programs, collecting their average execution time at different CPU frequencies (e.g., 2.6GHz, 2.2GHz, 1.8GHz). By establishing a response model between frequency and runtime, the system determines the program's tolerance to frequency variations. The evaluation results serve as a frequency sensitivity label for the corresponding task, automatically used for subsequent task classification and execution strategy formulation.

[0066] During test modeling, a database model is constructed based on experimental data. A standardized task input set is deployed in a controlled environment. Multiple typical frequencies are set through the CPU dynamic voltage and frequency adjustment interface. The program is run multiple times to record the average execution time and node energy consumption, constructing a performance-frequency response curve and forming a sensitivity model. Finally, automated scripts are used for batch analysis and periodic updates to the database. The system classifies sensitivity levels based on performance changes after a 20% frequency reduction: a performance decrease of ≥20% is considered high sensitivity, and frequency reduction is not recommended; a decrease of 10%~20% is considered medium sensitivity, and moderate frequency reduction is acceptable; a decrease of ≤10% is considered low sensitivity, and a larger frequency reduction is acceptable. This label is automatically attached to the task metadata during the task identification phase.

[0067] 2. Resume execution from breakpoint (whether the task can resume execution from the point of interruption after being interrupted). Resume execution from breakpoint refers to the ability of a task to continue execution from the point of interruption after it has been interrupted. Since this capability is mainly determined by the program design, the system identifies it through the explicit declaration made by the user when submitting the job.

[0068] 3. Interruptibility (whether the task can be interrupted during execution), 4. Delayability (whether the task must run immediately or can be postponed). Some critical business tasks (such as weather forecasting, emergency simulation, etc.) have extremely high requirements for continuity and timeliness, and usually do not allow interruption or delay. The system uses the information declared by the user when submitting the job, combined with the administrator's policy review mechanism, to jointly determine whether the task is a critical task that cannot be interrupted or delayed, and accordingly performs task identification, classification, and execution priority control.

[0069] All classification results are stored in the task control table to support subsequent operational strategies.

[0070] After classification, each supercomputing task is categorized according to the attributes and its importance is determined. The classified supercomputing tasks are then prioritized.

[0071] Table 1. Supercomputing Task Priority Classification Table

[0072] category Interruptible Recoverable Frequency reduction tolerance Delayable Description T1 no no no no Critical tasks currently in operation must not be interrupted, their frequency reduced, or their operation delayed; ensuring operational continuity must be a top priority. T2 no no yes no Critical tasks currently in operation should not be interrupted but can tolerate reduced frequency operation; a reduced frequency strategy should be applied when power is insufficient. T3 yes no no no A running task can be interrupted but cannot be resumed from the point of interruption; it does not have the ability to reduce frequency; it is suitable for emergency interruption scenarios. T4 yes no yes no The running task can be interrupted and has a certain tolerance for frequency reduction, but cannot be recovered after interruption. It is suitable for mild power fluctuations. T5 yes yes - no Running tasks can be interrupted and resumed at breakpoints. The system prioritizes interruption by default to release resources, and frequency tolerance is no longer considered. T6 - - - no Tasks that are pending and cannot be delayed must be run immediately when resources allow. T7 - - - yes Tasks that are waiting to run and can be delayed can have their execution postponed when power is low.

[0073] As shown in Table 1, the running supercomputing tasks are further divided into five categories according to three attribute dimensions: whether they can be downclocked, whether they can be interrupted, and whether they can be recovered. The supercomputing tasks to be run are further divided into two categories according to the attribute dimension: whether they can be delayed. T1-T5 are the priorities of the running supercomputing tasks, and T6 and T7 are the priorities of the supercomputing tasks to be run.

[0074] Among them, supercomputing tasks with priority T1 that cannot be downclocked, interrupted, recovered, or delayed are marked as the highest priority, supercomputing tasks with priority T5 that can be downclocked, interrupted, recovered, and delayed are marked as the lowest priority, and supercomputing tasks with priority T6 have a higher priority than T7.

[0075] To achieve dynamic response in green power sensing operation, the system automatically identifies and categorizes key operational attributes of tasks to support accurate matching of subsequent energy-saving strategies such as frequency reduction, interruption, and delay. This identification process relies on the Slurm job execution system and is carried out through the collaborative efforts of user declarations, system analysis, and administrator policies. Finally, the identification results are structured and written into the task control table, providing highly reliable real-time input for the operation module.

[0076] First, the task control table is designed. The system maintains a record for each running task. The record contains multiple fields such as job unique identifier, username, program information, frequency sensitivity, running attributes (whether it can be interrupted, resume from breakpoint, or run with a delay), resource usage, and running status. The task type is automatically classified by the combination of attributes, and the control status is dynamically updated according to the running strategy. These fields together provide data support for running decisions. The fields and corresponding codes of the record are shown in Table 2.

[0077] Table 2 records fields and corresponding codes.

[0078] field name type describe job_id STRING Slurm Job Unique Identifier user STRING Username for submitting the assignment job_name STRING Assignment Name program_name STRING Application name, extracted from the Command field. program_version STRING Application version frequency_sensitivity ENUM Program frequency sensitivity (high / medium / low) is provided by a frequency response database. recommended_freq_range STRING Recommended frequency reduction range (e.g., 2.6GHz–2.0GHz) interruptible BOOLEAN Whether runtime interruption is supported depends on user statements or administrator policies. checkpoint_enabled BOOLEAN Does it support resuming calculations from breakpoints? Delayable BOOLEAN Does it support delayed execution? task_type ENUM (T1~T7) The system automatically categorizes data based on attribute combinations. node_count INTEGER Current number of nodes in use runtime_elapsed TIME Runtime runtime_limit TIME Time limit runtime_remaining TIME Remaining runtime (calculated by the system) user_priority INTEGER User execution priority (obtained by the sprio command) current_state ENUM Current task status, such as RUNNING, PENDING, CANCELLED, etc. control_state ENUM The control state is initially set to NORMAL and is dynamically updated by the operating strategy. last_update_time DATETIME Record the timestamp of the last identification or update

[0079] When submitting a task, users must explicitly declare the execution control tags using Slurm's `--comment` parameter, including whether it can be interrupted, whether it supports resuming from a breakpoint, and whether it can be delayed. The declaration format is comma-separated key-value pairs. If not specified, the attributes will be completed according to default rules and administrator policies. Example submission command:

[0080] The command `sbatch --comment="interruptible=yes,checkpoint=enabled,delayable=no"run_job.slurm` means that a Slurm job script named `run_job.slurm` is submitted using the `sbatch` command, and the job is marked as interruptible, checkpoint enabled, and not delayable.

[0081] The system uses the Slurm command to obtain basic task runtime information and runtime declarations, extracting job identifiers, resource and runtime information, and program information. It also parses runtime attributes, obtains user priorities, and queries the "Application Frequency Response Database" based on the program name and version number to obtain frequency sensitivity and recommended frequency reduction ranges, thus populating the task control table fields. The system obtains basic task runtime information and runtime declarations using the following Slurm commands:

[0082] The command `squeue -o "%.18i %.9u %.8T %.50j %.10M %.10l %.6D"` displays job queue information in a specified format, including ID, user, status, name, run time, time limit, and number of nodes.

[0083] scontrol show job <jobid>(Displays detailed information for the specified job)

[0084] sprio --sort=I (Sort and display job priorities by priority index (I))

[0085] The system extracts the following key attributes from the command output and populates them into the task control table fields:

[0086] (1) Job identification information

[0087] job_id: Job ID (from %i);

[0088] user: Submitting user (from %u);

[0089] job_name: The task name (from %j);

[0090] current_state: Current state (from %T, such as RUNNING, PENDING, etc.);

[0091] (2) Resource and runtime information

[0092] runtime_elapsed: elapsed runtime (from %M);

[0093] runtime_limit: Maximum runtime of the task (from %l);

[0094] runtime_remaining: Remaining runtime, calculated by the system: runtime_remaining = runtime_limit - runtime_elapsed

[0095] node_count: Number of nodes in use (from %D);

[0096] (3) Extraction of program information

[0097] Extract the program name from the Command field to the program_name field, and extract the program version (if it can be parsed from the path or parameters) to the program_version field.

[0098] (4) Runtime attribute recognition

[0099] Parse the interruptible, checkpoint_enabled, and delayable parameters from the Comment field.

[0100] (5) User priority rating

[0101] Use the sprio command to retrieve the user_priority value (integer rating) corresponding to this task.

[0102] (6) Frequency response characteristics query

[0103] The system queries the "Application Frequency Response Database" based on the program name and version number to obtain:

[0104] frequency_sensitivity: The program's sensitivity level to CPU frequency (high / medium / low).

[0105] recommended_freq_range: Recommended safe freq range (e.g., 2.6GHz–2.0GHz);

[0106] In addition, the system supports an administrator policy overriding mechanism through a centralized configuration file. This mechanism allows system administrators to set mandatory attribute rules for specific tasks based on dimensions such as task name, username, application, or service level, ensuring that critical business tasks are confirmed by the system and preventing ordinary users from bypassing operational restrictions.

[0107] Administrator policies are stored in a centralized configuration file (supporting YAML / JSON formats). This file defines multiple rules, each containing task matching conditions and corresponding mandatory attribute settings. The system loads and matches this rule set during each task identification phase. If a rule is matched, the administrator-specified attributes override the user-declared or default values. The configuration file supports task matching based on the following fields:

[0108] Username

[0109] job_name

[0110] Application name program_name

[0111] Application version program_version

[0112] Service level (optional)

[0113] Once the rule is met, the following runtime attributes can be forcibly overridden:

[0114] interruptible: Whether it can be interrupted;

[0115] checkpoint_enabled: Whether to support resuming calculations after interruption;

[0116] delayable: Whether it can be delayed;

[0117] service_level: Service level label (e.g., CRITICAL / NORMAL).

[0118] During the task identification process, the system matches the fields in the task control table against the aforementioned rules. If a matching rule is found, the attribute values ​​in the `override` property override the user's declaration or default inference, and the task control table fields are updated. For tasks declared by the user as "uninterruptible" (interruptible=no) and "undelayable" (delayable=no), the system only identifies them as high real-time critical tasks (T1 category) if they simultaneously match the same mandatory settings in the administrator's rules. If the user declares these attributes but fails to pass the administrator's rule authentication, the system will automatically restore the default attributes (i.e., interruptible=yes, delayable=yes) and record an alarm log for review. This mechanism effectively prevents users from "disguising" themselves as critical tasks through false declarations, ensuring that the true priority of running resources is consistent with the system's trust boundaries.

[0119] Step S103: Based on the power supply and demand status and the priority of the supercomputing tasks, intelligently schedule the running order of the supercomputing tasks.

[0120] Specifically, first determine if there are any new tasks waiting to be run:

[0121] If there are no tasks to run, the system directly shuts down some idle computing nodes and unnecessary components to reduce the system's idle power consumption, and then enters the energy-saving operation strategy phase.

[0122] If there are tasks to be run, the system will process them according to their priority (determined by the task classification stage):

[0123] (1) For T7 type tasks (tasks that can be delayed), the system uses scontrol hold. <jobid>The command suspends it, which will postpone its execution and release its pre-requested resources, such as pre-allocated CPU cores or memory, to avoid increasing the system's power consumption burden.

[0124] (2) For T6 type tasks (critical tasks that cannot be delayed), the system will immediately arrange for their execution, giving priority to the use of currently available idle node resources to ensure the timeliness of task response. After the system executes a T6 type task, the task immediately becomes a running task. When energy saving and control are needed later, the system will identify the task attributes and reorder the task with other running tasks according to the priority of T1-T5. In this way, the priority of the task to be run is continuously converted into the priority of the running task.

[0125] After processing all pending tasks, the system will perform a unified energy consumption assessment on all idle computing nodes and, based on the actual green electricity gap, execute node shutdown strategies to further reduce overall energy consumption and release power redundancy for subsequent energy-saving operation phases. The system first obtains the list of currently idle nodes using the command `sinfo -t idle -o "%N"`, and then calls the `ipmitool` tool to perform remote shutdown operations on selected nodes, for example: `ipmitool -Ilanplus -H`.<BMC_IP> -U <user> -P <password>Chassis power off, which means: through the IPMI tool (ipmitool) to connect to the device with the lanplus interface to the specified BMC IP address, using the given username and password, to perform the operation of turning off the chassis power, to turn off the power of the idle node, and to release the system power redundancy. The BMC management interface address of the node <BMC_IP> can be automatically retrieved from the pre-configured node management mapping table.

[0126] After the running task processing is completed, if the system evaluation finds that there is still a power gap between green power supply and current computing load, the system enters the energy-saving regulation stage of the running task. In this stage, according to the preset task type priority from high to low (T1→T2→T3→T4→T5), continue to run the supercomputing task, and according to the priority from low to high (T5→T4→T3→T2→T1), evaluate and regulate (interrupt or reduce frequency) the running task in turn. The specific regulation implementation process of each type of task is as follows:

[0127] (1) T5 (interruptable, recoverable) task

[0128] Such tasks have complete breakpoint saving and restoring mechanism, and usually have no high time requirement. The system first filters all tasks marked as T5 type (interruptable and recoverable) from the task control table, calculates the "resource release potential" of the task based on resource occupation (preferentially selects tasks with more node occupation to achieve higher power consumption release efficiency), remaining running time (preferentially considers tasks with short running time but long expected remaining time to release the resources occupied for a long time) and user scheduling priority (preferentially interrupts ordinary tasks with low score), and generates a candidate interruption list t5_candidates[] in descending order, then traverses the list, and for each candidate task, executes the SLURM command scancel <job_id> (cancels the job with the specified ID in the Slurm scheduling system) to immediately terminate the task running, calls the scontrol show job <job_id> | grep NodeList (views the node list allocated by the specified job (<job_id>) in Slurm, filters out the line containing NodeList, and directly displays the node information of the running job) command to parse the node occupation information, uses the ipmitool -I lanplus -H <bmc_ip> -U admin -P password chassis power off command (where the BMC address <bmc_ip> is obtained from the system according to the node name to automatically find the preconfigured management address table) to perform remote shutdown on the nodes occupied by the task, and dynamically updates the total power consumption release value ΔP_current every time a batch of nodes are closed, and when ΔP_current≥green power gap ΔP_required, terminates the energy saving control process and resumes the normal running process, otherwise continues to process the next candidate task.

[0129] (2) T4 (interruptable, non-recoverable, and frequency-reducible) task

[0130] After interrupting the T5 type task, if it is detected that the power supply is still insufficient, the system identifies all tasks marked as T4 type, which do not have the ability to interrupt and recover, so the system adopts a two-stage energy saving strategy of "preferential frequency reduction and conditional interruption".

[0131] First, the frequency reduction strategy is preferentially executed to reduce the energy consumption load during the operation of tasks. The system calls the "frequency response database" to obtain the performance and energy consumption models of the application programs on which the tasks depend at different frequencies, and determines the recommended frequency reduction range accordingly (such as from 2.6 GHz to 2.0 GHz). Subsequently, the system preferentially filters out tasks that occupy a large number of nodes and have a long remaining running time as the objects of frequency reduction regulation. For the selected candidate tasks, the system sequentially executes the frequency reduction command on their running nodes. For programs with high tolerance, the allowable frequency reduction amplitude can be close to 30%; for programs with medium tolerance, the reduction amplitude is controlled within 10% - 20%. For example:

[0132] echo <2000000> / sys / devices / system / cpu / cpu* / cpufreq / scaling_setspeed (Set the frequency of all CPU cores to 2000000 kHz (i.e., 2 GHz))

[0133] After the frequency adjustment is completed, the system calculates the energy-saving contribution of each task according to "the number of nodes × the power consumption of a single node × the energy-saving ratio of frequency reduction", and accumulates it to the current released power consumption ΔP_current:

[0134] ΔP_current += the number of nodes × the node power consumption × the energy-saving ratio

[0135] After each frequency reduction, the system determines whether the current total energy-saving value reaches the green power gap ΔP_required. If it meets the standard, the regulation process of T4 type tasks is immediately terminated; if it does not meet the standard, the next candidate task is continued to be processed, and the frequency reduction operation is looped until all candidate tasks are processed.

[0136] If after executing all T4 tasks that can be frequency-reduced, the system determines that the current ΔP_current still does not meet the energy-saving target, it means that simply relying on the frequency reduction strategy cannot meet the green power limit requirements. At this time, the system switches to the interruption strategy. Preferentially select T4 tasks that have been frequency-reduced but have insufficient energy-saving contributions, and enforce the task interruption command:

[0137] scancel <job_id>

[0138] Subsequently, the system obtains the list of nodes occupied by the tasks through the node running information, and calls the remote management interface to execute the node power-off command, such as:

[0139] ipmitool -I lanplus -H <bmc_ip> -U admin -P password chassis poweroff

[0140] The system updates ΔP_current based on "number of nodes × node power consumption" and reassesses whether the green power supply and demand balance condition is met. If the target is not yet met, the system continues to process the next interruptible candidate task until the target is achieved or there are no remaining interruptible tasks.

[0141] (3) T3 (interruptible, non-recoverable, frequency-sensitive) task

[0142] After interrupting a T4 type task, if insufficient power supply is still detected, the system will use a direct interrupt strategy to release node resources and reduce system load for T3 type tasks that have interrupt capabilities but no recovery mechanism, are highly sensitive to CPU frequency changes, and have low energy-saving potential and high risk. The energy-saving control process is as follows:

[0143] First, identify T3 type tasks from the task control table, prioritizing tasks with a large number of nodes occupied, short running time but long remaining execution time, and low user scheduling priority scores. Then, use a resource release potential assessment model to sort these tasks from highest to lowest release potential to form a candidate interrupt task list t3_candidates[]. Next, iterate through this list and call the SLURM command to cancel each task.<job_id> Abort execution and update the task status to "unrecoverable termination", then call scontrol show job.<job_id> | Use `grep NodeList` to get a list of nodes, or use `ipmitool -Ilanplus -H`.<bmc_ip> -U admin -P password chassis power off remotely power off the nodes, update ΔP_current by estimating energy saving benefits based on the number of released nodes and node power consumption, and check in real time whether ΔP_current meets the green power gap ΔP_required after each interruption. If it does, the control is terminated and normal operation is resumed. If it does not meet the requirement, the next task is processed until the target is achieved or the candidate tasks are exhausted.

[0144] (4) T2 (non-interruptible, frequency-reducible) task

[0145] After interrupting T3-class tasks, if it is detected that the power supply is still insufficient, the system targets T2-class tasks that do not allow interruption. Such tasks are critical tasks but can adapt to frequency drops to a certain extent. Power consumption can be regulated by reducing the operating frequency, and all frequency reduction operations need to be executed based on the program characteristics provided by the frequency response database to ensure operating stability. The specific process is as follows: First, identify T2-type tasks, and prioritize tasks that occupy more nodes and have a longer running time. Then, query the frequency response model of the program used by each task to obtain the recommended frequency reduction range (e.g., 2.6 GHz → 2.0 GHz). Subsequently, send frequency reduction commands to each task running node one by one, dynamically set a reasonable frequency reduction amplitude, and control it within the range of 10% - 30%:

[0146] echo target_freq > / sys / devices / system / cpu / cpu* / cpufreq / scaling_setspeed. After frequency reduction, estimate the power consumption reduction value according to the energy-saving ratio in the frequency response model and record it in ΔP_current (the calculation formula is ΔP_current += N_nodes × P_node_avg × energy-saving ratio). If ΔP_current ≥ ΔP_required, terminate the energy-saving process. If not up to the standard, continue to process the next T2 task. A larger amplitude can be set for programs with strong tolerance to frequency reduction, and the reduction amplitude for performance-sensitive tasks is narrowed to ensure a balance between energy saving and performance.

[0147] (5)T1 (non-interruptible, frequency reduction sensitive) tasks

[0148] The system regards T1-class tasks as critical tasks. They are neither interruptible nor highly sensitive to frequency reduction, and the regulation space is extremely small. Such tasks are the key core tasks of the system, and limited frequency reduction operations are triggered only under extreme conditions after the regulation of T5 to T2-type tasks is completed and the green power still cannot meet the minimum operating power consumption requirement (i.e., ΔP_current < ΔP_required). Limited frequency reduction operations are performed on some T1 tasks running on high-frequency nodes, with large resource occupancy and whose calculation stage is in a non-critical path or can tolerate slight performance fluctuations. The frequency reduction range is strictly controlled between 10% and 15%, and it is only applied to tasks running on high-frequency nodes with high CPU load, such as executing echo <2400000> / sys / devices / system / cpu / cpu* / cpufreq / scaling_setspeed

[0149] The frequency is reduced to 2.4GHz to release a small amount of power consumption to ensure stable system operation. After each task is frequency reduced, the energy saving contribution value is estimated by ΔP_current += N_nodes × P_node_avg × frequency reduction energy saving ratio (generally not exceeding 5%) and added to ΔP_current. If ΔP_current ≥ ΔP_required, the frequency reduction process is terminated immediately.

[0150] After each frequency reduction or interruption operation, the system reassesses the difference between the current power consumption and the green power supply in real time, and determines whether the minimum operating power target has been reached. If power balance has been achieved, the system immediately terminates the energy-saving operation process and resumes normal operation; if not, it continues to process tasks according to priority until the green power supply and demand are balanced, or all adjustable task resources have completed their operations.

[0151] During energy-saving operation, the system queries the database based on the program name and version invoked by the task to obtain information such as sensitivity level and recommended frequency reduction range. Based on this, it dynamically sets the frequency, assesses energy-saving benefits, and controls the frequency reduction magnitude, ensuring that all operations do not exceed the model's recommended range, balancing task stability and energy-saving effects. Supported by this database, the system achieves precise analysis of program frequency sensitivity and scientific formulation of operational strategies, providing a crucial data foundation and technical support for green power sensing operation.

[0152] Preferably, when the system has completed all conventional energy-saving control measures, all interruptible, frequency-reduced, or delayable tasks have been processed, and only uninterruptible tasks of type T1 and uninterruptible but frequency-reduced tasks of type T2 are still running, and the green power supply is still insufficient to maintain the minimum operating power consumption, the system will enter an extreme low power state and activate the emergency handling mechanism.

[0153] This mechanism first triggers an emergency alarm, notifying maintenance personnel or the superior management platform. Simultaneously, the system systematically interrupts T2 and T1 tasks to minimize load. If an external backup power source (such as a diesel generator or energy storage device) is available, the system attempts to activate an emergency power supply to alleviate power pressure. If no emergency power source is available or the power supply remains insufficient, the system automatically switches to a minimum power standby mode, retaining only core monitoring and communication functions. It periodically checks power recovery status, and once power returns to a safe threshold, task scheduling automatically resumes. This mechanism ensures that the system maintains minimum operational capacity and self-recovery capability under extreme energy pressure until green power returns to a safe operating threshold.

[0154] In the solution provided by this method embodiment, the priority of supercomputing tasks is set according to the attributes of supercomputing tasks. When the power supply is insufficient, high-priority supercomputing tasks are run first while low-priority supercomputing tasks are suspended. The task execution strategy is dynamically adjusted, which significantly improves the utilization efficiency of green electricity, reduces the overall energy consumption of the system, and ensures the smooth execution of critical tasks under power constraints. This enhances the energy adaptability and operational resilience of the supercomputing system and promotes its continuous evolution towards green, efficient and intelligent directions.

[0155] Figure 3 A schematic diagram of a supercomputing task priority dynamic scheduling system adapted to green power fluctuations is provided in one embodiment of this application, as shown below. Figure 3 As shown, the system includes:

[0156] Status acquisition module 11: Used to acquire the power supply and demand status of the supercomputing system in real time;

[0157] Task classification module 22: When insufficient power supply is detected, it identifies the attributes of the current supercomputing task and classifies it, and sets the priority of the supercomputing task;

[0158] The task scheduling module 33 is used to intelligently schedule the running order of supercomputing tasks according to the power supply and demand status and the priority of the supercomputing tasks.

[0159] The above system can execute the supercomputing task priority dynamic scheduling method adapted to green power fluctuations in the foregoing embodiments, wherein,

[0160] The status acquisition module 11 executes step S101, the task classification module 22 executes step S102, and the task scheduling module 33 executes step S103.

[0161] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the supercomputing task priority dynamic scheduling method adapted to green power fluctuations in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0162] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0163] Figure 4 The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 1202 or a program loaded from a storage portion 1208 into a Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0164] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 1208 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet.

[0165] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 1201, it performs the functions defined in the methods of this application.

[0166] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0167] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0168] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0169] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0170] Another embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements a method for dynamic scheduling of supercomputing task priorities to adapt to green power fluctuations.

[0171] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0172] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0173] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0174] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods 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 page 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 an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0175] 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.

[0176] Furthermore, the functional units in the various embodiments of this application 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 in a combination of hardware and software functional units.

[0177] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0178] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0179] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.< / password> < / user> < / jobid> < / jobid>

Claims

1. A dynamic scheduling method for supercomputing tasks prioritizing tasks to adapt to fluctuations in green electricity, characterized in that, include: Real-time acquisition of power supply and demand status of the supercomputing system; When insufficient power supply is detected, the attributes of the current supercomputing tasks are identified and classified, and the priorities of the supercomputing tasks are set. Based on the power supply and demand status and the priority of the supercomputing tasks, the execution order of the supercomputing tasks is intelligently scheduled.

2. The supercomputing task priority dynamic scheduling method adapting to green power fluctuations according to claim 1, characterized in that, The real-time acquisition of the power supply and demand status of the supercomputing system further includes: Real-time acquisition of power supply and energy consumption of the supercomputing system; By comparing the power supply capacity with the energy consumption of the supercomputing system, it can be determined whether the current power supply and demand status should be maintained.

3. The supercomputing task priority dynamic scheduling method adapting to green power fluctuations according to claim 1, characterized in that, When insufficient power supply is detected, the process of identifying and classifying the attributes of the current supercomputing task and setting its priority further includes: Identify the attributes of the current supercomputing task, including: frequency sensitivity, ability to resume computation from breakpoints, interruptibility, and runtime delayability; Based on the aforementioned attributes, each supercomputing task is classified and its importance is determined. The classified supercomputing tasks are then prioritized.

4. The supercomputing task priority dynamic scheduling method adapting to green power fluctuations according to claim 3, characterized in that, The step of classifying each supercomputing task according to the attributes and determining its importance, and then prioritizing the classified supercomputing tasks, further includes: The supercomputing tasks are divided into two main categories: those currently running and those yet to be run. Based on three attribute dimensions—whether the frequency can be reduced, whether it can be interrupted, and whether it can be recovered—the running supercomputing tasks are further divided into five categories, and based on the attribute dimension—whether the supercomputing tasks to be run—the tasks to be run are further divided into two categories. Different priorities are assigned to each category based on the importance of the supercomputing task.

5. The supercomputing task priority dynamic scheduling method adapting to green power fluctuations according to claim 4, characterized in that, The intelligent scheduling of supercomputing task execution order based on the power supply and demand status and the importance of the supercomputing tasks further includes: Identify whether there are any supercomputing tasks waiting to be run, and if so, run them in order of priority. Identify the current power supply and demand status. If supply exceeds demand, shut down idle components. If supply is less than demand, run currently running supercomputing tasks in descending order of priority. Supercomputing tasks that are running will be interrupted or reduced in frequency in order of priority from low to high until supply and demand are balanced.

6. The supercomputing task priority dynamic scheduling method adapting to green power fluctuations according to claim 5, characterized in that, After intelligently scheduling the execution order of supercomputing tasks, the method further includes: If the power supply is still unable to maintain the current operation status of the supercomputing task after the intelligent scheduling of the supercomputing task execution order, an alarm will be triggered and the management personnel will be notified to start the emergency power supply.

7. A supercomputing task priority dynamic scheduling system adapted to green power fluctuations, characterized in that, include: Status acquisition module: used to acquire the power supply and demand status of the supercomputing system in real time; Task classification module: When insufficient power supply is detected, it identifies the attributes of the current supercomputing tasks, classifies them, and sets the priorities of the supercomputing tasks. The task scheduling module is used to intelligently schedule the execution order of supercomputing tasks based on the power supply and demand status and the priority of the supercomputing tasks.

8. A supercomputing task priority dynamic scheduling device adapted to green power fluctuations, characterized in that, The device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

9. A computer-readable medium having computer program instructions stored thereon, characterized in that, The computer program instructions can be executed by a processor to implement the method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images