Interrupt request processing method and device, equipment and storage medium

Abstract

The invention discloses an interrupt request processing method, device and equipment and a storage medium, and relates to the technical field of computer system optimizing.The method comprises the steps that according to monitored real-time interrupt loads of a plurality of processor cores of a server, a low-load core and a high-load core are divided; generating a migration decision result representing that the target interrupt request corresponding to the high-load core is migrated to the target processor core; the target processor core is a processor core, corresponding to the same NUMA domain as the high-load core, in the low-load cores; updating the affinity file corresponding to the target processor core by using the migration decision result, and adjusting the target mapping table in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table; the affinity file represents a binding relationship between the interrupt request and the processor core, and the target mapping table represents a data transmission relationship between a processing queue of a network card related to the interrupt request and the processor core. Therefore, the interrupt request can be dynamically migrated, and the problem of interrupt overload is relieved.

Description

Technical Field

[0001] This invention relates to the field of computer system optimization technology, and in particular to an interrupt request processing method, apparatus, device, and storage medium. Background Technology

[0002] With the stringent requirements for network throughput and latency in scenarios such as cloud computing, distributed databases, and high-frequency trading, server-side network interrupt handling, soft interrupt scheduling, and multi-queue mapping strategies have become system performance bottlenecks. Traditional static IRQ (Interrupt Request) core binding and RPS / XPS (Receive / Transmit Packet Steering) mapping lack adaptability to changes in traffic and CPU (Central Processing Unit) load, easily leading to problems such as interrupt storms, soft interrupt overload, uneven utilization of multi-core resources, and network queue imbalance.

[0003] It is evident that how to balance the load of interruption requests on the server is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to provide an interruption request processing method, apparatus, device, and storage medium that can solve the problem of server interruption request overload.

[0005] To address the aforementioned technical problems, in a first aspect, embodiments of the present invention provide an interruption request processing method, comprising:

[0006] Based on the real-time interrupt load of several processor cores of the server monitored, the processor cores are divided into low-load cores and high-load cores; low-load cores are those whose corresponding real-time interrupt load is less than a preset processor core load threshold, and high-load cores are those whose corresponding real-time interrupt load is not less than the preset processor core load threshold.

[0007] Based on the target processor core, a migration decision result is generated that represents the migration of the target interrupt request corresponding to the high-load core to the target processor core; the target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core.

[0008] Using the migration decision results, the affinity file corresponding to the target processor core is updated, and the target mapping table is adjusted in conjunction with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table. The affinity file is a file in the server that represents the binding relationship between the interrupt request and the processor core, and the target mapping table represents the data transmission relationship between the processing queue of the network card related to the interrupt request and the processor core.

[0009] In some embodiments, based on the monitored real-time interrupt load of several processor cores of the server, the processor cores are divided into low-load cores and high-load cores, including:

[0010] The first and second files are read based on a preset time period to count the number of each current interrupt request and the cumulative number of calls to the historical interrupt requests of the corresponding type in each processor core; the first file is a file representing the running status of soft interrupts, and the second file is a file representing the running status of hard interrupts.

[0011] Based on the quantitative relationship between the cumulative number of calls and the statistical time period, the call frequency of the current interrupt request and each processor core is calculated.

[0012] By collecting the cumulative execution time of historical interrupt requests on each processor core using preset probes, and combining this with the cumulative number of calls, the average execution time of the current interrupt request and its corresponding processor core is calculated.

[0013] The call frequency and average execution time corresponding to each current interrupt request are weighted and calculated to obtain the real-time interrupt load corresponding to several processor cores.

[0014] If the real-time interrupt load is not less than the preset processor core load threshold, the corresponding processor core will be identified as a high-load core.

[0015] If the real-time interrupt load is less than the preset processor core load threshold, the corresponding processor core will be identified as a low-load core.

[0016] In some embodiments, after obtaining the real-time interrupt load corresponding to several processor cores, the method further includes:

[0017] Real-time interrupt load is stored in a circular buffer so that pre-defined monitoring devices can retrieve and display the real-time interrupt load from the circular buffer through a pre-defined network service interface.

[0018] In some embodiments, based on the target processor core, a migration decision result is generated that represents migrating the target interrupt request corresponding to the high-load core to the target processor core, including:

[0019] Based on the preset migration strategy, and combined with the number of the target interrupt request corresponding to the target processor core and the high-load core and the original processor core, a migration decision result representing the migration of the interrupt request to the target processor core is generated.

[0020] The preset migration strategy is a migration strategy generated based on the type of interrupt request, the interrupt request and the list of operable components corresponding to the processor core.

[0021] In some embodiments, after executing the target interrupt request based on the adjusted mapping table, the method further includes:

[0022] Based on the relationship between the collected real-time performance metrics of the server and the preset performance metrics, the preset processor core load threshold and preset migration strategy are adjusted so that the adjusted processor core load threshold and the adjusted migration strategy can be used to handle relevant interrupt requests.

[0023] In some embodiments, the affinity file corresponding to the target processor core is updated using the migration decision results, and the target mapping table is adjusted in conjunction with the updated affinity file, including:

[0024] By using atomic write operations, the affinity file corresponding to the target processor core is updated using the migration decision results, resulting in the updated affinity file.

[0025] Several updated affinity files are cached using a temporary script, and the target mapping table is adjusted by combining several updated affinity files through a single system call.

[0026] In some embodiments, the method further includes:

[0027] Record the first configuration information of the affinity file before and after the update, and the second configuration information of the target mapping table before and after the adjustment;

[0028] When the server is in a failed adjustment state, the server state is rolled back using the first configuration information and the second configuration information; the failed adjustment state indicates that the performance after adjustment is less than the performance before adjustment.

[0029] Secondly, embodiments of the present invention provide an interruption request processing apparatus, comprising:

[0030] The processor core partitioning module is used to divide several processor cores into low-load cores and high-load cores based on the real-time interrupt load of several processor cores of the server. Low-load cores are those whose corresponding real-time interrupt load is less than a preset processor core load threshold, and high-load cores are those whose corresponding real-time interrupt load is not less than the preset processor core load threshold.

[0031] The migration decision module is used to generate a migration decision result based on the target processor core, which represents the migration of the target interrupt request corresponding to the high-load core to the target processor core; the target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core.

[0032] The interrupt request execution module is used to update the affinity file corresponding to the target processor core using the migration decision results, and adjust the target mapping table in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table. The affinity file is a file in the server that represents the binding relationship between the interrupt request and the processor core, and the target mapping table represents the data transmission relationship between the processing queue of the network card related to the interrupt request and the processor core.

[0033] Thirdly, embodiments of the present invention provide an electronic device, including:

[0034] Memory, used to store computer programs;

[0035] A processor is used to execute computer programs to implement the steps of the interrupt request handling method described above.

[0036] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the interrupt request handling method described above.

[0037] As can be seen from the above technical solution, this application first divides several processor cores into low-load cores and high-load cores based on the monitored real-time interrupt load of several processor cores in the server. Low-load cores are those whose corresponding real-time interrupt load is less than a preset processor core load threshold, and high-load cores are those whose corresponding real-time interrupt load is not less than the preset processor core load threshold. Then, based on the target processor core, a migration decision result is generated that represents the migration of the target interrupt request corresponding to the high-load core to the target processor core. The target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core. Then, the migration decision result is used to update the affinity file corresponding to the target processor core, and the target mapping table is adjusted in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table. The affinity file is a file in the server that represents the binding relationship between the interrupt request and the processor core, and the target mapping table represents the data transmission relationship between the processing queue of the network card related to the interrupt request and the processor core. Therefore, this solution can monitor real-time interrupt load and dynamically migrate relevant interrupt requests based on the processor core load, thereby alleviating interrupt overload. Furthermore, by updating the affinity files related to the interrupt request migration process, the relevant mapping tables can be adjusted simultaneously. This allows for real-time response to sudden traffic surges and resolves network queue imbalance issues. Attached Figure Description

[0038] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 A flowchart of an interruption request processing method provided in an embodiment of the present invention;

[0040] Figure 2 This is a schematic diagram of an interrupt request processing system framework provided by an embodiment of the present invention;

[0041] Figure 3 A server monitoring flowchart provided in this embodiment of the invention;

[0042] Figure 4 A migration decision flowchart provided in an embodiment of the present invention;

[0043] Figure 5 A migration execution flowchart is provided as an embodiment of the present invention;

[0044] Figure 6 A closed-loop verification flowchart is provided for an embodiment of the present invention;

[0045] Figure 7 This is a schematic diagram of an interrupt request processing device disclosed in an embodiment of the present invention;

[0046] Figure 8 This is a structural diagram of an electronic device disclosed in an embodiment of the present invention. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0048] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0049] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0050] To address the issue of network interrupt handling, soft interrupt scheduling, and multi-queue mapping strategies becoming system performance bottlenecks on the server side, the commonly used approach is static interrupt binding to cores. However, this mapping strategy lacks adaptability to changes in traffic and processor load, easily leading to interrupt storms and interrupt overload. To resolve these issues, this application monitors real-time interrupt load and, in conjunction with processor core load, dynamically migrates relevant interrupt requests to alleviate interrupt overload. Furthermore, by updating affinity files related to the interrupt request migration process, the relevant mapping tables can be adjusted simultaneously to ensure consistency in intermediate states. This allows for real-time response to sudden traffic surges and resolves network queue imbalances.

[0051] like Figure 1 As shown, this embodiment discloses an interruption request handling method, including:

[0052] Step S11: Based on the monitored real-time interrupt load of several processor cores of the server, divide the processor cores into low-load cores and high-load cores; low-load cores are processor cores whose corresponding real-time interrupt load is less than a preset processor core load threshold, and high-load cores are processor cores whose corresponding real-time interrupt load is not less than a preset processor core load threshold.

[0053] In this embodiment, the server's load status is first monitored to detect the load related to interrupt requests. Specifically, various server metrics can be monitored, such as real-time interrupt load information for each processor core. Then, by combining the monitored real-time interrupt load with a pre-set load threshold, the status of each processor core in the server can be determined. Specifically, processor cores with real-time interrupt loads less than a preset processor core load threshold are identified as low-load cores, and those with real-time interrupt loads not less than the preset processor core load threshold are identified as high-load cores. In a specific embodiment, the server monitoring process can deploy eBPF (Extended Berkeley Packet Filter, a kernel extension technology) probes to hook kernel functions (irq_handler_entry and softirq_entry) to sample interrupt-related load information.

[0054] In one specific embodiment, classifying several processor cores into low-load cores and high-load cores based on the monitored real-time interrupt load of several processor cores of the server may include: reading a first file and a second file based on a preset time period to count the number of each current interrupt request and the cumulative number of calls to historical interrupt requests of the corresponding type on each processor core; the first file is a file representing the operation of soft interrupts, and the second file is a file representing the operation of hard interrupts; calculating the call frequency of the current interrupt request corresponding to each processor core based on the quantitative relationship between the cumulative number of calls and the statistical time period; collecting the cumulative execution time of historical interrupt requests on each processor core through a preset probe, and calculating the average execution time of the current interrupt request corresponding to each processor core based on the cumulative number of calls; performing a weighted calculation on the call frequency and average execution time corresponding to each current interrupt request to obtain the real-time interrupt load corresponding to several processor cores; if the real-time interrupt load is not less than a preset processor core load threshold, the corresponding processor core is determined to be a high-load core; if the real-time interrupt load is less than the preset processor core load threshold, the corresponding processor core is determined to be a low-load core. Specifically, interrupt-related files on the server can be read periodically based on time cycles to collect interrupt-related load information. For example, reading ` / proc / interrupts` (hard interrupt execution status) and ` / proc / softirqs` (soft interrupt execution status) files can collect and statistically analyze the cumulative number of calls to each IRQ number and the CPU core containing the soft interrupt type. Combining the cumulative number of calls with the number of sampling periods (the difference in call counts before and after sampling divided by the sampling period), the call frequency of interrupt requests corresponding to each processor core can be calculated, i.e., the call frequency of the current interrupt request on each processor core. Furthermore, by deploying eBPF probes and hooking kernel functions, the execution time of each interrupt handling and soft interrupt can be collected, enabling fine-grained monitoring of interrupt execution time. It should be noted that the average interrupt handling time needs to consider the cumulative interrupt execution time and the number of calls to obtain the average execution time of the current interrupt request corresponding to each processor core. Then, combining the interrupt-related call frequency and average execution time, a corresponding comprehensive index is obtained through weighted calculation, which serves as the load index. The weighting calculation can be configured according to actual conditions. This weighted method yields the server's real-time interrupt load. Furthermore, based on the relationship between the monitored real-time interrupt load and the pre-set processor core load threshold, processor cores can be divided into high-load cores and low-load cores. Understandably, high-load cores are overloaded and need to offload some interrupts, while low-load cores have lower loads and can accept some interrupt migration, alleviating the pressure on overloaded cores.

[0055] In another specific embodiment, after obtaining the real-time interrupt load corresponding to several processor cores, the method may further include: storing the real-time interrupt load in a circular buffer, so that a preset monitoring device can retrieve and display the real-time interrupt load from the circular buffer through a preset network service interface. Specifically, after detecting server-related real-time interrupt load, the real-time interrupt load can be recorded, the monitored load can be stored in a circular buffer, and a network service interface can be set so that other monitoring devices can retrieve the stored server's real-time interrupt load and display it visually, making it easier for relevant personnel to understand the server's real-time status.

[0056] Step S12: Based on the target processor core, generate a migration decision result that represents the migration of the target interrupt request corresponding to the high-load core to the target processor core; the target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core.

[0057] In this embodiment, the real-time interrupt load of the server is monitored through the above steps, and high-load cores and low-load cores are determined based on the real-time interrupt load. Then, by considering the NUMA (Non-Uniform Memory Access) node corresponding to the processor core, high-load cores and low-load cores within the same NUMA node are identified. Finally, a processor core is selected from the low-load cores as the target processor core corresponding to the high-load core. It is understood that the target processor core is a low-load core, with a lower load, which can accommodate some interrupt migrations, alleviating the pressure on the overloaded core. Then, a migration decision result is generated, representing the migration of the target interrupt request corresponding to the high-load core to the target processor core. This migration decision result may include information such as the interrupt request number, the target processor core, and the original processor core.

[0058] It should be noted that the target processor core can be any processor core in the same NUMA node as the high-load core. Alternatively, based on the real-time load, the low-load cores in the NUMA node can be sorted in ascending order of load, and the processor core with the lowest load can be selected as the target processor core. Interrupt migration can also be performed according to the pre-set processor core type or other special requirements. Suitable processor cores can be flexibly selected for interrupt migration.

[0059] In one specific embodiment, based on the target processor core, generating a migration decision result representing the migration of a target interrupt request corresponding to a high-load core to the target processor core can include: generating a migration decision result representing the migration of the interrupt request to the target processor core based on a preset migration strategy, combined with the target processor core, the number corresponding to the target interrupt request of the high-load core, and the original processor core; wherein, the preset migration strategy is a migration strategy generated based on the type of interrupt request, the operable list corresponding to the interrupt request and / or processor core. Specifically, in the process of generating the migration decision result, different migration strategies can be set, such as selecting different processor cores according to different types of interrupt requests, whitelists and blacklists of interrupt requests or processor cores, etc.; combining these parameters allows for flexible selection of migration strategies for interrupt requests. In a specific embodiment, to avoid frequent migration of the same interrupt request, the number of cycles before the migration operation for the same interrupt request can also be considered, for example, setting that the interrupt request can only be migrated once in three time cycles to prevent frequent switching.

[0060] Step S13: Using the migration decision results, update the affinity file corresponding to the target processor core, and adjust the target mapping table in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table; the affinity file is a file in the server that represents the binding relationship between the interrupt request and the processor core, and the target mapping table represents the data transmission relationship between the processing queue of the network card related to the interrupt request and the processor core.

[0061] In this embodiment, the interrupt load information of each processor core of the server can be considered through the above steps. Some low-load cores are selected as target processor cores, and migration decision results are generated to migrate some interrupt requests from high-load cores to target processor cores. This achieves interrupt request migration and alleviates the load pressure on high-load cores. Based on the migration decision results, the affinity file of the target processor core can be updated, that is, the target interrupt requests to be migrated are written to the affinity file corresponding to the target processor core. This achieves interrupt migration and binds the interrupt to the target processor core. Furthermore, the relevant target mapping table can be adjusted based on the updated affinity file, adjusting the data transmission relationship between the processing queue of the relevant network interface card and the target processor core, so that the target interrupt request can be executed through the target processor core based on the adjusted mapping table. This ensures intermediate state consistency and improves migration reliability.

[0062] In one specific embodiment, the affinity file corresponding to the target processor core is updated using the migration decision result, and the target mapping table is adjusted in conjunction with the updated affinity file. This can include: updating the affinity file corresponding to the target processor core using the migration decision result through an atomic write operation to obtain an updated affinity file; caching several updated affinity files using a temporary script, and adjusting the target mapping table in conjunction with these updated affinity files through a single system call. Specifically, during the process of updating the affinity file, the affinity file of the target processor core can be updated using the migration decision result through an atomic write operation to achieve interrupt migration and obtain the corresponding updated affinity file; subsequently, several updated affinity files generated by the migration can be cached through a temporary script, and several updated affinity files can be submitted in batches through a single system call to adjust the target mapping table and ensure the consistency of the intermediate state. It should be noted that during the process of updating the affinity file, the custom parameters of the relevant network interface card can be adjusted to optimize the overall interrupt migration effect.

[0063] In another specific embodiment, after executing the target interrupt request based on the adjusted mapping table, the process may further include: adjusting a preset processor core load threshold and a preset migration strategy based on the relationship between the collected real-time performance metrics of the server and preset performance metrics, so as to process the relevant interrupt requests using the adjusted processor core load threshold and the adjusted migration strategy. Specifically, after migrating interrupt requests from high-load cores of the server to low-load cores and executing them, the server's real-time performance metrics can be collected to evaluate whether the server performance before and after the migration meets the relevant requirements; for example, if the server performance improvement after interrupt migration is not significant, the migration strategy can be adjusted, considering migrating the relevant interrupt requests to other processor cores, or adjusting the processor core load threshold to alleviate the load pressure on the processor cores in a timely manner.

[0064] In another specific embodiment, it may further include: recording first configuration information of the affinity file before and after the update, and second configuration information of the target mapping table before and after the adjustment; when the server is in an adjustment failure state, using the first and second configuration information to roll back the server's state; the adjustment failure state indicates that the performance after adjustment is less than the performance before adjustment. Specifically, to ensure the reliability of the server, the server's configuration information (affinity bitmap, mapping table, load threshold, load calculation weight, etc.) can be recorded before and after the interrupt migration, i.e., maintaining historical configuration snapshots; when the execution result of a server in response to an interrupt request does not meet expectations, i.e., the server's interrupt migration does not meet expectations (performance changes before and after adjustment do not meet expectations, execution results are lower than a certain performance index), and the server is in an adjustment failure state, the pre-recorded historical configuration snapshots can be used to roll back the server's state; this can roll the server back to the previous optimal configuration state, ensuring the server's reliability.

[0065] Therefore, this application can monitor real-time interrupt load and dynamically migrate relevant interrupt requests based on the processor core load, thereby alleviating interrupt overload and reducing single-core quiescence. Furthermore, by updating the affinity files related to the interrupt request migration process, the relevant mapping tables can be adjusted simultaneously to ensure intermediate state consistency. This allows for real-time response to sudden traffic surges without requiring a system restart, enabling online deployment to address network queue imbalance issues, supporting configuration rollback, and ensuring system reliability.

[0066] like Figure 2 As shown in the diagram, the interrupt request handling method framework involved in this technical solution can be divided into four modules: a monitoring module, a decision-making module, an execution module, a self-scheduling module, and a closed-loop verification module. The interrupt request handling method of this solution will be described below with reference to specific embodiments, including:

[0067] In this embodiment, the monitoring module can periodically read multiple metrics of the server to obtain the scheduling frequency and execution duration of each network interface card IRQ and Soft IRQ (soft interrupt) on each core. For example... Figure 3As shown, during server monitoring, interrupt load information can be periodically collected. By reading the ` / proc / interrupts` and ` / proc / softirqs` files, the cumulative number of calls to each IRQ number and the CPU core containing the soft interrupt type can be counted. Simultaneously, using deployed eBPF probes to hook kernel functions `irq_handler_entry` and `softirq_entry`, the duration of each interrupt handling and soft interrupt execution can be sampled, enabling fine-grained monitoring of interrupt execution time. Furthermore, a ring buffer can be used to store the most recent N sampled data, which is exposed to the decision module via the shared memory interface ` / dev / shm / irq_monitor`, allowing the decision module to determine whether to trigger interrupt migration based on the sampled data. In a specific embodiment, a RESTful (Representational State Transfer, a software architectural style involving application programming interfaces) interface can be provided to support monitoring systems such as Prometheus (an open-source monitoring system) in pulling and visualizing key metrics. It should be noted that interrupt frequency is involved here. Specifically, the call rate of each interrupt on each core is obtained by dividing the difference in the number of calls before and after sampling by the sampling period. The average processing time of soft interrupts is obtained by dividing the cumulative execution time collected by eBPF by the number of calls. The load factor is a weighted combination of interrupt frequency and average processing time to form a comprehensive load index (the weights can be freely configured according to the actual situation).

[0068] Furthermore, such as Figure 4As shown, during the migration decision-making process, the decision-making module can combine a pre-set load threshold, detect the network load of the server periodically, and determine whether to perform a core switching operation or a回迁 operation; among them, the migration decision result corresponding to the core switching operation includes the IRQ number, the original bound core, and the target bound core. Specifically, first configure the high load threshold $T_high and the low load threshold $T_low, for example, $T_high = 80% and $T_low = 20%, to judge the core load status. Obtain the load factor $L_i of each core from the monitoring module and compare it with the threshold: if $L_i > T_high, it can be considered that core $i is in an overloaded state and some interrupts need to be unloaded; if $L_i < T_low and there are overloaded cores, it means that the load of this core is low and it can accept the interrupt migration of other overloaded cores. Accordingly, among all the low-load cores with $L_j < T_low, the core $j that is in the same NUMA domain as the source core (high-load core) and has the lowest load can be preferentially selected as the migration target; then generate the decision result set $D = (IRQ_k, core_i, core_j), which includes the IRQ number to be migrated, the original bound core $core_i, and the target bound core $core_j$. In a specific embodiment, the following parameters can be supported for configuration: the hysteresis count is the minimum number of cycles required to be satisfied before the same IRQ is migrated continuously multiple times, to prevent frequent switching; the black and white list can configure the key IRQ or core white list to avoid migration affecting key services; the custom weight can adjust the weights of different soft interrupt types or hard interrupts in the load factor calculation.

[0069] Furthermore, as Figure 5 It should be noted that the term "回迁操作" in the original text seems to be a misspelling or an undefined term. I translated it as "回迁操作" as it is, but it might need to be corrected or further clarified in the original context.As shown, during the interrupt migration process, the execution module first reads the migration decision set D to determine the current migration instruction. Based on the migration instruction, interrupt migration is performed. Furthermore, in case of execution failure or performance degradation, the historical configuration can be automatically rolled back and logs recorded. Specifically, it first receives the migration instruction $(IRQ_k, core_i, core_j)$ from the decision module and calculates the affinity bitmap mask_j corresponding to the target processor core $core_j$. An atomic write operation is performed: `echomask_j> / proc / irq / IRQ_k / smp_affinity`, completing the dynamic migration of the hard interrupt. Custom parameters of the network card can be adjusted during this process. Then, all interrupt affinity bitmaps and queue mappings that need updating are written to a temporary script or cache and submitted in batches through a single system call to avoid intermediate state inconsistencies. It is understandable that before and after the interrupt request migration, the parameters and return status before and after each affinity and RPS / XPS mapping update can be recorded in the logs. This allows for automatic rollback after a migration failure, restoring the configuration to its state before the migration update, and marking the failure in the logs. In specific embodiments, algorithm parameters such as thresholds, weights, blacklists and whitelists can be dynamically adjusted through configuration files or application programming interfaces, and historical configuration snapshots can be maintained. When the execution result is lower than the preset performance index (such as a decrease in throughput), it can be automatically rolled back to the previous optimal configuration.

[0070] After that, as Figure 6 As shown, during the closed-loop verification process for interrupt migration, the closed-loop verification module periodically detects and makes decisions to verify relevant performance indicators. The verification results are then used to optimize load thresholds and migration strategies, forming an adaptive closed loop. Specifically, a monitoring-decision-execution process is triggered at a fixed period $t (e.g., 5 seconds) to ensure continuous adaptation to changes in network and system load. In specific embodiments, hysteresis counters and minimum switching interval parameters can be used to prevent frequent switching of the same IRQ or queue, optimizing anti-jitter performance. During interrupt request processing, key performance indicators such as network throughput (Packets Per Second), sys CPU (the percentage of time the processor spends in kernel mode), and application layer latency can be collected synchronously and compared with the set target indicators to calculate performance gains or degradations, assessing the impact of interrupt migration on network load. Based on the results, load thresholds or migration strategy weights can be adjusted to achieve closed-loop optimization.

[0071] Therefore, this application can monitor real-time interrupt load and dynamically migrate relevant interrupt requests based on the processor core load, thereby alleviating interrupt overload. Furthermore, by updating the affinity files related to the interrupt request migration process, the relevant mapping tables can be adjusted simultaneously. This allows for real-time response to sudden traffic surges, maximizes the use of multi-queue network cards to reduce cache jitter, smoothly handles sudden traffic surges, eliminates the need to restart the system, and supports online deployment and rollback.

[0072] like Figure 7 As shown, this embodiment discloses an interruption request processing device, including:

[0073] The processor core partitioning module 11 is used to partition several processor cores into low-load cores and high-load cores based on the real-time interrupt load of several processor cores of the server monitored; low-load cores are processor cores whose corresponding real-time interrupt load is less than a preset processor core load threshold, and high-load cores are processor cores whose corresponding real-time interrupt load is not less than a preset processor core load threshold.

[0074] The migration decision module 12 is used to generate a migration decision result based on the target processor core, which represents the migration of the target interrupt request corresponding to the high-load core to the target processor core; the target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core.

[0075] Interrupt request execution module 13 is used to update the affinity file corresponding to the target processor core using the migration decision result, and adjust the target mapping table in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table; the affinity file is a file in the server that represents the binding relationship between the interrupt request and the processor core, and the target mapping table represents the data transmission relationship between the processing queue of the network card related to the interrupt request and the processor core.

[0076] Therefore, this application can monitor real-time interrupt load and dynamically migrate relevant interrupt requests based on the processor core load, thereby alleviating interrupt overload. Furthermore, by updating the affinity file related to the interrupt request migration process, the relevant mapping table can be adjusted simultaneously. This allows for real-time response to sudden traffic surges and resolves the problem of network queue imbalance.

[0077] Furthermore, embodiments of this application also disclose an electronic device, Figure 8This is a structural diagram of an electronic device according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the interrupt request handling method disclosed in any of the foregoing embodiments. Furthermore, the electronic device in this embodiment may specifically be an electronic computer.

[0078] In this embodiment, the power supply 23 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 24 can create a data transmission channel between the electronic device and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0079] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0080] The operating system 221 is used to manage and control the various hardware devices on the electronic device and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the interrupt request handling method executed by the electronic device as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0081] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed interrupt request handling method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0082] Furthermore, this application also discloses a computer program product, including a computer program / instruction that, when executed by a processor, implements the aforementioned disclosed interrupt request handling method.

[0083] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0084] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0085] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0086] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0087] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An interruption request handling method, characterized in that, include: Based on the real-time interrupt load of several processor cores of the server monitored, the processor cores are divided into low-load cores and high-load cores. The low-load core is a processor core whose real-time interrupt load is less than a preset processor core load threshold, and the high-load core is a processor core whose real-time interrupt load is not less than the preset processor core load threshold. Based on the target processor core, a migration decision result is generated that represents the migration of the target interrupt request corresponding to the high-load core to the target processor core; The target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core; Using the migration decision results, the affinity file corresponding to the target processor core is updated, and the target mapping table is adjusted in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table; The affinity file is a file in the server that represents the binding relationship between interrupt requests and processor cores, and the target mapping table represents the data transmission relationship between the processing queue of the network interface card related to the interrupt request and the processor core.

2. The interruption request processing method according to claim 1, characterized in that, The step of dividing the processor cores into low-load cores and high-load cores based on the monitored real-time interrupt load of several processor cores of the server includes: The first and second files are read based on a preset time period to count the number of each current interrupt request and the cumulative number of calls to the historical interrupt requests of the corresponding type in each processor core; the first file is a file representing the running status of soft interrupts, and the second file is a file representing the running status of hard interrupts. Based on the relationship between the cumulative number of calls and the statistical time period, the call frequency of the current interrupt request and each processor core is calculated. The cumulative execution time of the historical interrupt requests on each processor core is collected by a preset probe, and the average execution time of the current interrupt request and each processor core is calculated by combining the cumulative number of calls. The real-time interrupt load corresponding to each current interrupt request is calculated by weighting the call frequency and the average execution time to obtain the real-time interrupt load corresponding to several processor cores. If the real-time interrupt load is not less than the preset processor core load threshold, then the corresponding processor core is determined to be a high-load core; If the real-time interrupt load is less than the preset processor core load threshold, the corresponding processor core is determined to be a low-load core.

3. The interruption request processing method according to claim 2, characterized in that, After obtaining the real-time interrupt load corresponding to the plurality of processor cores, the method further includes: The real-time interrupt load is stored in a circular buffer so that a preset monitoring device can obtain and display the real-time interrupt load from the circular buffer through a preset network service interface.

4. The interruption request processing method according to claim 2, characterized in that, The step of generating a migration decision result based on the target processor core, representing the migration of the target interrupt request corresponding to the high-load core to the target processor core, includes: Based on a preset migration strategy, and combining the target processor core, the number corresponding to the target interrupt request of the high-load core, and the original processor core, a migration decision result representing the migration of the interrupt request to the target processor core is generated. The preset migration strategy is a migration strategy generated based on the type of interrupt request, the interrupt request and / or the list of operable components corresponding to the processor core.

5. The interruption request processing method according to claim 4, characterized in that, After executing the target interrupt request based on the adjusted mapping table, the process further includes: Based on the relationship between the collected real-time performance metrics of the server and the preset performance metrics, the preset processor core load threshold and the preset migration strategy are adjusted so as to handle relevant interrupt requests using the adjusted processor core load threshold and the adjusted migration strategy.

6. The interruption request processing method according to claim 1, characterized in that, The step of updating the affinity file corresponding to the target processor core using the migration decision result, and adjusting the target mapping table based on the updated affinity file, includes: The affinity file corresponding to the target processor core is updated using the migration decision results through an atomic write operation, resulting in an updated affinity file. Several updated affinity files are cached using a temporary script, and the target mapping table is adjusted using these updated affinity files in a single system call.

7. The interruption request processing method according to any one of claims 1 to 6, characterized in that, Also includes: Record the first configuration information of the affinity file before and after the update, and the second configuration information of the target mapping table before and after the adjustment; When the server is in an adjustment failure state, the server's state is rolled back using the first configuration information and the second configuration information; the adjustment failure state indicates that the performance after adjustment is less than the performance before adjustment.

8. An interrupt request processing apparatus, characterized in that, include: The processor core partitioning module is used to partition the processor cores into low-load cores and high-load cores based on the real-time interrupt load of the monitored processor cores of the server; the low-load cores are processor cores whose real-time interrupt load is less than a preset processor core load threshold, and the high-load cores are processor cores whose real-time interrupt load is not less than the preset processor core load threshold. The migration decision module is used to generate a migration decision result based on the target processor core, which represents migrating the target interrupt request corresponding to the high-load core to the target processor core; The target processor core is any processor core in the low-load core that corresponds to the same NUMA domain as the high-load core; The interrupt request execution module is used to update the affinity file corresponding to the target processor core using the migration decision result, and adjust the target mapping table in combination with the updated affinity file, so as to execute the target interrupt request based on the adjusted mapping table; The affinity file is a file in the server that represents the binding relationship between interrupt requests and processor cores, and the target mapping table represents the data transmission relationship between the processing queue of the network interface card related to the interrupt request and the processor core.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the interrupt request handling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the interrupt request handling method as described in any one of claims 1 to 7.

Images