A resource adaptive configuration method and system for crash dump system

Abstract

The application provides a resource adaptive configuration method and system for a crash dump system, pre-control is performed during kernel crash dump service kdump loading initialization, differentiated calculation strategies are implemented on different types of high memory consumption drivers in the driver list, if a dynamic memory demand peak exceeds a reserved memory capacity, an original dump image and a service start sequence are suspended, a kernel boot parameter with a target driver blacklist instruction is added to a kdump start command line, a safe dump image is reconstructed and generated, and kernel crash dump service kdump loading is completed; when the kernel crash dump service kdump is triggered, a physical memory field vmcore kernel dump file is generated based on the safe dump image. Through memory measurement and adaptive decision, the dump image is reconstructed, and non-key redundant high memory consumption drivers are dynamically cleared, so that the OOM hidden danger in the initial stage of dumping is completely eliminated, and dumping success is ensured.

Description

Technical Field

[0001] This invention belongs to the field of computer operating system technology, specifically relating to a resource adaptive configuration method and system for crash dump systems. Background Technology

[0002] In the fields of operating system high availability and kernel fault diagnosis, the kernel crash dump service kdump is a crucial line of defense for Linux systems when a fatal kernel panic occurs, extracting the physical memory context (vmcore) for post-event root cause analysis. kdump works by using the kexec system call to quickly boot into a pre-reserved kernel-specific area called crashkernel without restarting the system.

[0003] Currently, in Linux systems, memory allocation and kernel building for kdump capture mainly follow two traditional technical paths: 1. Static memory allocation method: By modifying the bootloader's configuration file, a fixed-size physical memory region can be reserved for the capture kernel as a static value. This fixed value is usually determined based on historical maintenance experience or vendor recommendations, lacking dynamic awareness of the current hardware load and the memory overhead of the underlying drivers.

[0004] 2. Static dependency building method: During the dump environment generation and service startup phase, the system uses the dracut tool to construct the initialization memory disk initramfs / kdump.img for capturing the kernel. This mechanism packages dependencies based on the current host's hardware configuration, including kernel modules already loaded in the production environment (such as various network device drivers) and packs them into the initramfs of the captured kernel.

[0005] However, the aforementioned traditional technologies still have certain shortcomings in the actual production and operation of cloud-native and high-performance computing: 1. The structural contradiction between static resource pre-allocation and the dynamic, massive overhead of hardware drivers: Traditional technologies cannot dynamically detect the dynamic surge in memory demand brought about by peripheral drivers with strong memory preemption characteristics before the dump environment is built. For example, the high-speed network card driver mlx5_ib generates huge dynamic overhead on the host's physical memory during the initialization phase. This imperceptible deep loss is directly brought into the capture kernel with extremely limited resources, causing the capture kernel to trigger OOM due to memory exhaustion and be forcibly killed by the system, thus completely missing the physical opportunity to generate the vmcore kernel dump file.

[0006] 2. The dilemma of reserving memory: If we want to change the way resources are statically pre-allocated, we will face the dilemma of not being able to avoid both resource waste and failed dumping.

[0007] This dilemma is particularly prominent in cloud-native and high-performance computing production environments: blindly increasing the reserved memory by multiples in order to prevent OOM will irreversibly occupy and squeeze the effective physical resources of the production environment in the long term, resulting in a huge waste of business costs; while maintaining a conservative reservation faces a high risk of dump failure.

[0008] 3. The blind construction of the kernel capture method is seriously misaligned with the actual core requirements of the dump: The sole core objective of kernel capture is to quickly and safely migrate the main kernel's physical memory data to the target storage medium after a fatal system crash. However, existing dracut build mechanisms employ a blind, all-inclusive loading logic, packaging a massive amount of hardware drivers from the production system into the captured kernel's initramfs. For example, even when the dump target is explicitly the local disk, the system may still load resource-intensive but useless heavy-duty network communication drivers. These network card drivers consume significant amounts of memory, and loading them in a kdump environment can cause serious problems, significantly increasing the risk of OutOfMemoryError (OOM).

[0009] 4. Lack of pre-assessment and adaptive degradation mechanisms: Existing crash dump fault tolerance mechanisms are highly outdated. Current kdump memory debugging methods mainly rely on the rd.memdebug=[0-3] parameter of dracut, but this method is insufficient for debugging fine-grained memory consumption at the kernel module level. When it is necessary to identify which kernel module is consuming a large amount of memory, rd.memdebug cannot provide effective assistance. Therefore, even under severe memory deficits, the build and loading process is allowed by default, and it is impossible to automatically and intelligently trigger degradation decisions.

[0010] While existing technologies offer a fixed blacklist mechanism as a remedy, this mechanism has significant limitations: First, the blacklist relies on the post-event manual judgment of operations and maintenance personnel, which is a passive trial-and-error process; second, the blacklist lacks awareness of the differentiated dependencies of the target storage path and cannot make dynamic decisions based on actual dumping requirements; third, when hardware topology changes or driver version upgrades cause changes in memory consumption characteristics, the existing blacklist configuration may no longer be applicable.

[0011] In summary, the existing kernel crash dump service kdump has significant shortcomings in terms of deterministic resource allocation, differentiated awareness of the capture environment construction, and pre-emptive quantitative assessment and adaptive degradation. Summary of the Invention

[0012] The purpose of this invention is to provide a resource adaptive configuration method and system for crash dump systems. By introducing memory calculation and adaptive adjudication based on hardware topology before the dump is triggered, non-critical redundant high memory consumption drivers are eliminated, and the dump image is reconstructed. This allows for the dynamic removal of non-critical redundant high memory consumption drivers without affecting production operations, thereby completely eliminating the OOM (Out of Memory) risk in the early stages of the dump and ensuring the success of the crash site dump with optimal system resource consumption.

[0013] To achieve the above objectives, the technical solution of the present invention is as follows: An adaptive resource allocation method for crash dump systems includes: S1. Execute pre-control during the kernel crash dump service kdump loading initialization, take over and pause the service startup sequence, obtain the allocated reserved memory capacity, and extract the list of drivers to be loaded from the dump image. S2. Construct a differentiated dynamic memory estimation model, implement differentiated calculation strategies for different types of high memory consumption drivers in the driver list, calculate the initial estimated memory of each driver and calculate the sum of the initial estimated memory, add the sum of the initial estimated memory to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump. S3. Compare the reserved memory capacity with the peak dynamic memory demand. If the peak dynamic memory demand exceeds the reserved memory capacity, suspend the original dump image and service startup sequence, and activate step S4. S4. Append kernel boot parameters with a blacklist of target drivers to the kdump boot command line, wherein the target drivers include non-critical, redundant, high-memory-consumption drivers. S5. Reconstruct the dump image using the kdump dump component building tool to generate a safe dump image that completely excludes the non-critical redundant high memory consumption drivers. S6. Reload the security dump image, cancel the suspension of the service startup sequence, and complete the loading of the kernel crash dump service kdump; S7. When the kernel crash dump service kdump is triggered, a physical memory scene vmcore kernel dump file is generated based on the security dump image.

[0014] Furthermore, step S1 includes: Based on systemd overriding configuration, a pre-triggered interception is performed to pause and take over the dump service startup sequence before the kernel load command occurs. Read the underlying control node and extract the reserved memory capacity currently actually allocated to the kernel crash dump service kdump; The system's embedded low-level parsing tool is invoked to perform deep parsing on the original dump image kdump.img, extract the list of drivers to be loaded from the dump image, and classify and identify high memory-consuming drivers into regular Ethernet standard drivers and high-performance unloaded drivers.

[0015] Furthermore, step S2 includes: For the standard Ethernet drivers in the driver list, calculate the initial estimated memory based on the system queue parameters Rx / Tx Rings and the network maximum transmission unit (MTU). Unload the high-performance state driver in the driver list, extract the device configuration feature file System Profile at the firmware level, strip out the underlying concurrent connections and index extreme values, and calculate the initial estimated memory. The calculated initial estimated memory for each driver is summed to obtain the total initial estimated memory. The total initial estimated memory is then added to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump.

[0016] Furthermore, in step S3, the statement that the peak dynamic memory demand exceeds the reserved memory capacity means that the boundary of the reserved memory capacity is absolutely smaller than the peak dynamic memory demand.

[0017] Furthermore, in step S4, the identification of non-critical, redundant high-memory-consumption drivers includes: Parse the global dump configuration file and extract the dump target configuration to establish the hardware link of the dump path; Read the system's underlying virtual file system to identify the device subsystem category to which the target driver belongs; Cross-compare the hardware link with the device subsystem category to which the target driver belongs. If the hardware link is on the local medium and there is no intersection between the target driver and the hardware link, then the target driver belongs to a non-critical redundant high memory consumption driver.

[0018] Furthermore, in step S4, kernel boot parameters with blacklisted instructions for the target driver are appended to the kdump startup command line, including: taking over the global state configuration of the kernel crash dump service kdump, performing configuration injection using a streaming append patching mechanism based on regular expression matching, and injecting kernel boot parameters with blacklisted instructions for the target driver.

[0019] Furthermore, in step S5, before the dump image is reconstructed, verification logic is also executed to read and compare the file status parameters before and after the configuration injection, and to compare whether the kernel boot parameters with the target driver blacklist instructions have been correctly written and retained in the command line environment.

[0020] Furthermore, step S6 includes: The secure dump image is stored in reserved memory that has been allocated for the kernel crash dump service kdump; Revoke the suspension control over the service startup sequence and return execution control of service startup; Complete the subsequent loading of the kernel crash dump service kdump.

[0021] Furthermore, step S7 includes: When an irreversible and serious error occurs in the host operating system backbone, the kernel crash dump service kdump is triggered. The kernel in the reserved memory is captured, the highest control privilege is obtained, the secure dump image is loaded, and the physical memory scene vmcore kernel dump file is generated.

[0022] In another aspect, this invention proposes a resource adaptive allocation system for crash dump systems, comprising: Pre-control module: Performs pre-control during the kernel crash dump service kdump loading initialization, takes over and pauses the service startup sequence, obtains the allocated reserved memory capacity, and extracts the list of drivers to be loaded from the dump image; Model building module: Constructs a differentiated dynamic memory estimation model, implements differentiated calculation strategies for different types of high memory consumption drivers in the driver list, calculates the initial estimated memory of each driver and calculates the sum of the initial estimated memory, adds the sum of the initial estimated memory to the basic system overhead of kdump, and obtains the peak dynamic memory requirement of kdump. Comparison and Suspension Module: Compares the reserved memory capacity with the peak dynamic memory demand. If the peak dynamic memory demand exceeds the reserved memory capacity, the original dump image and service startup sequence are suspended, and the command line append module is activated. Command line append module: Appends kernel boot parameters with a blacklist of target drivers to the kdump boot command line, including non-critical, redundant, high-memory-consuming drivers. Secure Dump Image Module: The dump image is reconstructed using the kdump dump component building tool to generate a secure dump image that completely excludes the non-critical redundant high memory consumption drivers; Suspension and Cancellation Module: Reloads the security dump image, cancels the suspension of the service startup sequence, and completes the loading of the kernel crash dump service kdump; Triggering module: When the kernel crash dump service kdump is triggered, it generates a physical memory state vmcore kernel dump file based on the secure dump image.

[0023] Compared with the prior art, the present invention has the following significant advantages: 1. This invention proposes a service pre-interception method based on systemd configuration overriding, which intercepts and takes over the startup process of dumped services without changing the native scheduling component code of the operating system. This avoids the potential risk of the defense mechanism configuration failing due to major version upgrades of system components.

[0024] 2. This invention proposes an algorithm model for accurately quantifying memory consumption of high memory-consuming drivers. It not only solves the problem of difficulty in quantifying the memory overhead of unloaded drivers in high-performance states, but also accurately calculates the potential dynamic physical memory peak of the device before actually taking over kernel execution. At the same time, it proposes a linear calculation formula for memory consumption measurement for conventional Ethernet standard drivers, forming a parallel calculation mechanism.

[0025] 3. This invention proposes a pre-judgment mechanism for underlying OOM risk based on supply and demand comparison, which overturns the traditional delayed approach of discovering errors only after the fact and conducting troubleshooting. It achieves the goal of verifying the event in a normal state before it occurs, thereby ensuring a decisive advantage in subsequent error avoidance.

[0026] 4. This invention proposes a hierarchical dynamic injection method for blacklist instructions of non-critical redundant high memory consumption drivers, which shifts the exclusion of target drivers from simple service isolation to the core physical layer.

[0027] 5. This invention proposes a method for reconstructing and replacing dump images, which physically eliminates any potential OOM (Out of Memory) risks and ensures the success of crash site dumping with optimal system resource consumption. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the scheme architecture of Embodiment 1 of the present invention; Figure 2 This is a flowchart of Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the system structure of Embodiment 3 of the present invention. Detailed Implementation

[0029] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0030] The design concept of this invention is to propose a configuration technology that can predict peak memory consumption without loss based on objective hardware characteristics, can perform environmental differentiation perception across software and hardware boundaries, and has the ability to intercept and self-heal in advance.

[0031] The present invention will now be described in detail with reference to specific embodiments and accompanying drawings.

[0032] Example 1: This embodiment is based on the overall scheme architecture proposed by the design concept of the present invention, such as... Figure 1 As shown, it includes: Supply-side fact-driven lossless review and interception mechanism: This embodiment introduces pre-resource review during the startup or reload phase of the kernel crash dump service kdump. The lsinitrd parsing tool deeply deconstructs the constructed capture kernel initialization disk initramfs / kdump.img to accurately extract the actual packaged list of underlying kernel modules. Based on the absolute objective facts of the kdump startup environment, this mechanism extracts the actual reserved memory capacity allocated to the capture kernel, serving as a baseline for static resource supply and providing highly deterministic pre-interception and data support for system resource allocation.

[0033] A differentiated dynamic memory estimation model for heterogeneous hardware: This embodiment constructs a non-intrusive differentiated dynamic memory estimation model for heterogeneous hardware. Differentiated calculation strategies are implemented for different types of high-memory-consumption drivers: For standard Ethernet drivers, estimation is performed by reading system queue parameters Rx / Tx Rings and the network maximum transmission unit (MTU); for high-performance state-unloaded drivers such as RDMA / IB (e.g., mlx5_ib smart NIC drivers), the system dynamically detects the PCI-E topology and smart NIC firmware capabilities, including the maximum concurrent queue size (max_qp) and the maximum memory mapping size (max_mr), to calculate the hidden overhead of hardware state unloading forcibly requisitioning host physical memory. This model achieves accurate memory estimation during the driver initialization phase of the kdump initialization process without driver unloading in a production environment.

[0034] Environmental Target Awareness and Supply-Demand Conflict Adaptive Resolution Engine: This embodiment sets up an environmental target awareness and supply-demand conflict adaptive resolution engine. First, it dynamically determines the mandatory dependency attributes of high-overhead target drivers. Based on this, the system compares the reserved memory capacity with the peak dynamic memory demand of kdump. The peak dynamic memory demand of kdump is calculated by adding the sum of the initial estimated memory of each high memory-consuming driver calculated by the differentiated dynamic memory estimation model to the basic system overhead of kdump. Once it is determined that the reserved memory capacity cannot support the peak dynamic memory demand of kdump and there is a risk of system OOM (Out of Memory), the system uses the pre-instruction of the native service manager and the ExecStartPre mechanism of systemd to legally take over and suspend the service startup sequence of kdump, preventing the blind physical loading of the capture kernel.

[0035] Dynamic Isolation and Image Reconstruction Mechanism for Supply-Demand Conflicts: This embodiment designs a pre-intervention scheme based on prediction and configuration injection to address supply-demand conflict scenarios. When it is determined that the current system's reserved memory capacity cannot support the dynamic memory demand peak of kdump, the system proactively intervenes during the normal runtime of the kernel crash dump service kdump, i.e., before the kernel executes a panic jump. This is achieved by dynamically modifying system-level dump configuration files such as ` / etc / sysconfig / kdump`, automatically appending kernel boot parameters with a blacklist of target drivers (non-critical, redundant, high-memory-consumption drivers) to the kdump startup command line. Subsequently, the system triggers a build refresh mechanism, executing `kdumpctl rebuild` to reconstruct the dump image, and triggering a service reload `systemctl restart` to reload the reconstructed secure dump image. This mechanism ensures that a brand-new, lightweight, secure dump image with explicit isolation instructions is pre-transmitted to the underlying reserved memory. When the kernel crash dump service kdump is triggered, the capturing kernel will skip the initialization logic of such non-critical and redundant high memory-consuming drivers, thereby curbing unexpected memory squeezes and cutting off the OOM cascading crashes on the dump side from the physical root, ensuring the successful generation of vmcore.

[0036] Example 2: This embodiment is based on the architecture described in Embodiment 1, and presents the process of a resource adaptive configuration method for crash dump systems, as follows: Figure 2 As shown, it includes: S1. During the kernel crash dump service kdump loading initialization, perform pre-control, take over and suspend the service startup sequence, obtain the allocated reserved memory capacity, and extract the list of drivers to be loaded from the dump image.

[0037] This step is implemented based on the supply-side fact-driven lossless review interception mechanism in the architecture, specifically as follows: 1.1 Pre-triggered interception based on systemd overridden configuration: When kdump is triggered to start, the system does not immediately execute the loading of the original dump image. Instead, the system accesses the service configuration directory, enters the ` / etc / systemd / system / kdump.service.d / ` level, dynamically distributes a service override configuration file `override.conf` to the system, and writes the `ExecStartPre` pre-command to this file. Through this native interception mechanism provided by systemd, the system can pause and legally take over the kdump service startup sequence before executing the `kexec -p` kernel loading command. Unlike traditional solutions that require direct modification of the underlying service source code, this step uses standard override configuration for isolation and interception. The entire process does not require modification of any operating system core file code, completely eliminating the security risk of the defense mechanism failing due to upgrades or updates of underlying components.

[0038] 1.2 Reserved memory for reading: After the pre-interception takes effect, the internal evaluation program immediately begins to collect and calculate resource data. First, it directly reads the underlying control node (e.g., the virtual file / sys / kernel / kexec_crash_size) to accurately extract the actual reserved memory capacity currently allocated to kdump by the operating system, which is the size of the crashkernel. This is used as the static memory supply threshold for the subsequent dump stage.

[0039] 1.3 Extracting the list of drivers with high memory consumption: To address the blind spots inherent in experience-based estimations, the evaluation program directly invokes the system's embedded low-level parsing tool, executing the `lsinitrd` image parsing command to perform deep unpacking of the natively built initial memory disk file `initramfs / kdump.img`. By searching the path information of the device driver tree within the packaged image, it extracts a list of high-memory-consuming drivers (such as the `mlx5_ib` smart network card driver) that will be loaded with the kernel after a system crash. Based on the suffix and its network stack category, the extracted target drivers are classified and identified qualitatively, distinguishing between standard Ethernet drivers and high-performance state-offloading drivers. The "state offloading" in high-performance state-offloading drivers refers to transferring the complex state information originally maintained by the software CPU to the hardware for direct management and maintenance. Therefore, high-performance state-offloading drivers are drivers that offload a large number of complex processing tasks from the CPU to the hardware for execution. For example, the driver for the high-performance smart network card `mlx5_ib` is a high-performance state-offloading driver. This driver allows the smart network card hardware to take over the complex and heavy state management work in RDMA communication, achieving offloading from the CPU and thus bringing high-performance network communication.

[0040] S2. Construct a differentiated dynamic memory estimation model, implement differentiated calculation strategies for different types of high memory consumption drivers in the driver list, calculate the initial estimated memory of each driver and calculate the sum of the initial estimated memory, add the sum of the initial estimated memory to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump.

[0041] This step is implemented based on the differentiated dynamic memory estimation model for heterogeneous hardware in the architecture, specifically as follows: After extracting and classifying drivers with high memory consumption, the system no longer relies on the statically compiled disk size of the driver file to estimate its memory usage. Instead, it automatically mounts a differentiated dynamic memory prediction model and enters the corresponding algebraic prediction branch. For standard Ethernet drivers: Read the underlying network interface layer node, such as / sys / class / net / <device name> / queues, and capture the queue parameters Rx / Tx Rings, including the total number of receive and transmit queues of the current standard Ethernet driver device and the core queue depth parameter Ring Size. Combine this with the currently configured Maximum Transmission Unit (MTU) to calculate the single buffer step size. Then, using the algorithm formula: Initialized estimated memory = total number of queues × queue depth × single buffer step size + device basic residency overhead, accurately calculate the dynamic memory consumption limit based on the DMA ring buffer.

[0042] For high-performance state offloading drivers: Given that high-performance state offloading drivers perform state offloading at the hardware level, their core memory black holes often stem from the massive internal cache and memory translation tables that must be forcibly requested from the host's physical isolation area. Therefore, we can instead extract the device configuration feature file System Profile at the firmware level, which determines the maximum scale of the underlying concurrency support. From this, we can directly extract the extreme values ​​of the underlying concurrent connections and indices, obtaining parameters including the maximum concurrency queue pair size (max_qp), the maximum memory mapping size (max_mr), MTT translation mapping entry overhead, etc. Substituting these parameters into the formula: Initialized estimated memory = Maximum concurrency queue pair size (max_qp) × Single qp context state overhead + (Maximum memory mapping size (max_mr) × MTT translation mapping entry overhead) + Device basic residency overhead. This allows for the first time high-precision, lossless initialization estimated memory derivation for black-box high-performance state offloading drivers.

[0043] By using a differentiated dynamic memory prediction model, the previously deeply hidden implicit memory overhead during hardware runtime is completely transformed into a precise quantitative indicator table, providing clear data basis for the physical threshold hedging of subsequent OOM anti-crash determination.

[0044] The estimated initial memory usage of all high memory-consuming drivers is summed, and then this sum is added to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump.

[0045] S3. Compare the reserved memory capacity with the peak dynamic memory demand. If the peak dynamic memory demand exceeds the reserved memory capacity, suspend the original dump image and service startup sequence, and activate step S4.

[0046] This step is implemented based on the environmental goal awareness and supply-demand conflict adaptive adjudication engine in the architecture, specifically as follows: 3.1 Real-time hedging of memory supply and demand thresholds and qualitative assessment of OOM risk: The reserved memory capacity obtained in S1 is rigidly compared with the peak dynamic memory demand calculated in S2 using mathematical cross-comparison. Once it is determined that the reserved memory capacity is less than (absolutely less than) the peak dynamic memory demand, the system qualitatively concludes that, under the current kernel architecture, the moment the capture kernel takes over the host after a disaster, there is an inevitable risk of a 100% deterministic OOM (Out of Memory) cascading crash. The system immediately generates an anomaly warning in response to this conclusion.

[0047] 3.2 Topology-aware driven differentiated classification and isolation labeling: Upon receiving an anomaly warning signal, the system does not directly exclude all high memory consumption drivers and does not perform loading in the capture kernel; instead, it immediately performs contextual business topology tracing of the dump environment.

[0048] Specifically, the system first parses the global dump configuration file / etc / kdump.conf and extracts its dump target configuration to determine the hardware links required for the dump path, such as local disk I / O links or network transmission links.

[0049] Subsequently, the system mounts and retrieves the hardware dependency tree of the high memory consumption driver: by reading the underlying virtual file system of the operating system, it identifies the subsystem category of the device to which the high memory consumption driver belongs.

[0050] The hardware links required for the dump path are cross-referenced with the subsystem categories. If the analysis engine determines that the target dump path is on local media and depends on the storage subsystem, and the subsystem category of the high memory consumption driver has no intersection with the hardware links required for the dump path on the hardware dependency tree of this high memory consumption driver, then it can be determined that the driver has no rationale for existence in the subsequent underlying disk I / O business core flow, that is, it qualitatively possesses the "business decoupling non-critical redundancy characteristic". Based on this, the system marks such non-critical redundant high memory consumption drivers with a security isolation suspension marker for forced architectural decoupling, providing a target for subsequent operations.

[0051] S4. Append kernel boot parameters with a blacklist of target drivers to the kdump boot command line, wherein the target drivers include non-critical, redundant, high-memory-consuming drivers.

[0052] This step, along with subsequent steps S5 and S6, is implemented based on the dynamic isolation and mirror reconstruction mechanism in the architecture to address supply and demand conflicts. Specifically, this step involves: All non-critical, redundant, high-memory-consumption drivers with forced architectural decoupling security isolation suspension flags are grouped into a target driver blacklist.

[0053] This mechanism takes over the global state configuration control layer of kdump, employing a streaming append-and-paste mechanism based on regular expression matching for configuration injection. It injects kernel boot parameters containing blacklisted instructions for the target driver into the operating system's capture kernel control baseline (a set of kernel boot parameters used to control capture kernel behavior and resources, set and managed via the KDUMP_COMMANDLINE_APPEND configuration variable). For example, it explicitly issues and appends the command `modprobe.blacklist=mlx5_ib`. By reshaping the underlying control of configuration variables, it blocks the loading of non-critical, redundant, high-memory-consuming drivers from the target driver blacklist in the boot environment.

[0054] S5. Reconstruct the dump image using the kdump dump component building tool to generate a safe dump image that completely excludes the non-critical redundant high memory consumption drivers.

[0055] This step is specifically as follows: 5.1 Completeness verification of substantial changes to configuration files: Given that the original dump image kdump.img consumes significant CPU and disk I / O resources, the system needs to reconstruct a lightweight, secure dump image. A completeness verification logic is implemented before executing the reconstruction instructions. By reading and comparing the file status parameters before and after the configuration injection in step S4, the system accurately extracts and compares whether the kernel boot parameters containing the target driver's blacklist instructions have been correctly written and retained in the command-line environment. This verification mechanism effectively filters out false positives caused by invalid operations such as single timestamp updates or harmless space changes, completely avoiding the operating system from being trapped in unnecessary resource consumption due to frequent recompilation triggered by minor file format adjustments.

[0056] 5.2 New Image Reconstruction Based on Isolation Configuration Rules: Once the integrity check is passed, the system wakes up the kdump underlying dump component building tool, initiates the kdumpctl rebuild process, and performs image reconstruction.

[0057] During the compilation and packaging process, the build program is strictly restricted to following the masking rules of the newly injected target driver blacklist in the system; the target drivers in the blacklist are physically set to null. Finally, the system compiles and produces a brand-new security dump image that completely eliminates the non-critical redundant high memory-consuming drivers and has highly lightweight features. This security dump image is a newly simplified kdump.img file.

[0058] S6. Reload the security dump image, cancel the suspension of the service startup sequence, and complete the loading of the kernel crash dump service kdump.

[0059] This step is specifically as follows: The secure dump image is stored in the reserved memory allocated for kdump. Then, the system actively revoks the suspension control previously applied to the service startup sequence, returning subsequent service execution control to the operating system's native service manager. kdump then completes the subsequent standard loading and switches to a standard background daemon state, without affecting any business performance of the current system. At this point, the entire resource adaptation and dynamic pruning process is complete.

[0060] S7. When the kernel crash dump service kdump is triggered, a physical memory scene vmcore kernel dump file is generated based on the security dump image.

[0061] When the system actually encounters a kernel crash (Panic event) that triggers the kernel crash dump service kdump, kdump will take over directly, capture the kernel (Crashkernel) and immediately obtain the highest control privileges. Relying on the loading of a lightweight and secure dump image, it eliminates high memory-consuming drivers that have large underlying queue request requirements but are non-critical and redundant. This ensures that within the reserved memory, the total memory occupied by the kernel crash dump service kdump during the full device registration and initialization process will always stay below the safety threshold of the reserved memory capacity, avoiding OOM and successfully completing the generation of the physical memory-based vmcore kernel dump file.

[0062] This embodiment introduces memory calculation and adaptive adjudication based on hardware topology before the dump is triggered, and reconstructs the dump image. This enables the dynamic removal of non-critical and redundant high memory-consuming drivers without affecting production operations, thereby completely eliminating the OOM risk in the early stage of the dump and ensuring the success of the crash site dump with optimal system resource consumption.

[0063] Example 3: This embodiment proposes a resource adaptive configuration system for crash dump systems, such as... Figure 3 As shown, it includes: Pre-control module: Performs pre-control during the kernel crash dump service kdump loading initialization, takes over and pauses the service startup sequence, obtains the allocated reserved memory capacity, and extracts the list of drivers to be loaded from the dump image; Model building module: Constructs a differentiated dynamic memory estimation model, implements differentiated calculation strategies for different types of high memory consumption drivers in the driver list, calculates the initial estimated memory of each driver and calculates the sum of the initial estimated memory, adds the sum of the initial estimated memory to the basic system overhead of kdump, and obtains the peak dynamic memory requirement of kdump. Comparison and Suspension Module: Compares the reserved memory capacity with the peak dynamic memory demand. If the peak dynamic memory demand exceeds the reserved memory capacity, the original dump image and service startup sequence are suspended, and the command line append module is activated. Command line append module: Appends kernel boot parameters with a blacklist of target drivers to the kdump boot command line, including non-critical, redundant, high-memory-consuming drivers. Secure Dump Image Module: The dump image is reconstructed using the kdump dump component building tool to generate a secure dump image that completely excludes the non-critical redundant high memory consumption drivers; Suspension and Cancellation Module: Reloads the security dump image, cancels the suspension of the service startup sequence, and completes the loading of the kernel crash dump service kdump; Triggering module: When the kernel crash dump service kdump is triggered, it generates a physical memory state vmcore kernel dump file based on the secure dump image.

[0064] The front-end control module includes: Based on systemd overriding configuration, a pre-triggered interception is performed to pause and take over the dump service startup sequence before the kernel load command occurs. Read the underlying control node and extract the reserved memory capacity currently actually allocated to the kernel crash dump service kdump; The system's embedded low-level parsing tool is invoked to perform deep parsing on the original dump image kdump.img, extract the list of drivers to be loaded from the dump image, and classify and identify high memory-consuming drivers into regular Ethernet standard drivers and high-performance unloaded drivers.

[0065] The model building module includes: For the standard Ethernet drivers in the driver list, calculate the initial estimated memory based on the system queue parameters Rx / Tx Rings and the network maximum transmission unit (MTU). Unload the high-performance state driver in the driver list, extract the device configuration feature file System Profile at the firmware level, strip out the underlying concurrent connections and index extreme values, and calculate the initial estimated memory. The calculated initial estimated memory for each driver is summed to obtain the total initial estimated memory. The total initial estimated memory is then added to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump.

[0066] In the comparison and suspension module, the statement that the peak dynamic memory demand exceeds the reserved memory capacity means that the boundary of the reserved memory capacity is absolutely smaller than the peak dynamic memory demand.

[0067] In the command-line append module, the identification of non-critical, redundant, high-memory-consumption drivers includes: Parse the global dump configuration file and extract the dump target configuration to establish the hardware link of the dump path; Read the system's underlying virtual file system to identify the device subsystem category to which the target driver belongs; Cross-compare the hardware link with the device subsystem category to which the target driver belongs. If the hardware link is on the local medium and there is no intersection between the target driver and the hardware link, then the target driver belongs to a non-critical redundant high memory consumption driver.

[0068] The command-line append module appends kernel boot parameters with blacklisted instructions for the target driver to the kdump startup command line. This includes: taking over the global state configuration of the kernel crash dump service kdump, performing configuration injection using a streaming append patching mechanism based on regular expression matching, and injecting kernel boot parameters with blacklisted instructions for the target driver.

[0069] Before the security dump image module reconstructs the dump image, it also performs verification logic, reads and compares the file status parameters before and after the configuration injection, and compares whether the kernel boot parameters with the target driver blacklist instructions have been correctly written and retained in the command line environment.

[0070] The suspend / cancel module includes: The secure dump image is stored in reserved memory that has been allocated for the kernel crash dump service kdump; Revoke the suspension control over the service startup sequence and return execution control of service startup; Complete the subsequent loading of the kernel crash dump service kdump.

[0071] The trigger module includes: When an irreversible and serious error occurs in the host operating system backbone, the kernel crash dump service kdump is triggered. The kernel in the reserved memory is captured, the highest control privilege is obtained, the secure dump image is loaded, and the physical memory scene vmcore kernel dump file is generated.

[0072] The resource adaptive configuration system for crash dump systems proposed in this embodiment can achieve the resource adaptive configuration method for crash dump systems described in Embodiment 2, and has the same technical effect.

[0073] The above-described embodiments are merely preferred embodiments of the present invention and are only used to help understand the method and core ideas of this application. The scope of protection of the present invention is not limited to the above embodiments, and all technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A resource adaptive allocation method for crash dump systems, characterized in that, include: S1. Execute pre-control during the kernel crash dump service kdump loading initialization, take over and pause the service startup sequence, obtain the allocated reserved memory capacity, and extract the list of drivers to be loaded from the dump image. S2. Construct a differentiated dynamic memory estimation model, implement differentiated calculation strategies for different types of high memory consumption drivers in the driver list, calculate the initial estimated memory of each driver and calculate the sum of the initial estimated memory, add the sum of the initial estimated memory to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump. S3. Compare the reserved memory capacity with the peak dynamic memory demand. If the peak dynamic memory demand exceeds the reserved memory capacity, suspend the original dump image and service startup sequence, and activate step S4. S4. Append kernel boot parameters with a blacklist of target drivers to the kdump boot command line, wherein the target drivers include non-critical, redundant, high-memory-consumption drivers. S5. Reconstruct the dump image using the kdump dump component building tool to generate a safe dump image that completely excludes the non-critical redundant high memory consumption drivers. S6. Reload the security dump image, cancel the suspension of the service startup sequence, and complete the loading of the kernel crash dump service kdump; S7. When the kernel crash dump service kdump is triggered, a physical memory scene vmcore kernel dump file is generated based on the security dump image.

2. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, Step S1 includes: Based on systemd overriding configuration, a pre-triggered interception is performed to pause and take over the dump service startup sequence before the kernel load command occurs. Read the underlying control node and extract the reserved memory capacity currently actually allocated to the kernel crash dump service kdump; The system's embedded low-level parsing tool is invoked to perform deep parsing on the original dump image kdump.img, extract the list of drivers to be loaded from the dump image, and classify and identify high memory-consuming drivers into regular Ethernet standard drivers and high-performance unloaded drivers.

3. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, Step S2 includes: For the standard Ethernet drivers in the driver list, calculate the initial estimated memory based on the system queue parameters Rx / Tx Rings and the network maximum transmission unit (MTU). Unload the high-performance state driver in the driver list, extract the device configuration feature file System Profile at the firmware level, strip out the underlying concurrent connections and index extreme values, and calculate the initial estimated memory. The calculated initial estimated memory for each driver is summed to obtain the total initial estimated memory. The total initial estimated memory is then added to the basic system overhead of kdump to obtain the peak dynamic memory requirement of kdump.

4. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, In step S3, the peak dynamic memory demand exceeding the reserved memory capacity means that the boundary of the reserved memory capacity is absolutely smaller than the peak dynamic memory demand.

5. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, In step S4, the identification of non-critical, redundant, high-memory-consumption drivers includes: Parse the global dump configuration file and extract the dump target configuration to establish the hardware link of the dump path; Read the system's underlying virtual file system to identify the device subsystem category to which the target driver belongs; Cross-compare the hardware link with the device subsystem category to which the target driver belongs. If the hardware link is on the local medium and there is no intersection between the target driver and the hardware link, then the target driver belongs to a non-critical redundant high memory consumption driver.

6. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, In step S4, kernel boot parameters with blacklisted instructions for the target driver are appended to the kdump startup command line. This includes: taking over the global state configuration of the kernel crash dump service kdump, performing configuration injection using a streaming append patching mechanism based on regular expression matching, and injecting kernel boot parameters with blacklisted instructions for the target driver.

7. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, Before reconstructing the dump image in step S5, verification logic is also executed to read and compare the file status parameters before and after the configuration injection, and to compare whether the kernel boot parameters with the target driver blacklist instructions have been correctly written and retained in the command line environment.

8. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, Step S6 includes: The secure dump image is stored in reserved memory that has been allocated for the kernel crash dump service kdump; Revoke the suspension control over the service startup sequence and return execution control of service startup; Complete the subsequent loading of the kernel crash dump service kdump.

9. The resource adaptive allocation method for a crash dump system according to claim 1, characterized in that, Step S7 includes: When an irreversible and serious error occurs in the host operating system backbone, the kernel crash dump service kdump is triggered. The kernel in the reserved memory is captured, the highest control privilege is obtained, the secure dump image is loaded, and the physical memory scene vmcore kernel dump file is generated.

10. A resource adaptive allocation system for crash dump systems, characterized in that, include: Pre-control module: Performs pre-control during the kernel crash dump service kdump loading initialization, takes over and pauses the service startup sequence, obtains the allocated reserved memory capacity, and extracts the list of drivers to be loaded from the dump image; Model building module: Constructs a differentiated dynamic memory estimation model, implements differentiated calculation strategies for different types of high memory consumption drivers in the driver list, calculates the initial estimated memory of each driver and calculates the sum of the initial estimated memory, adds the sum of the initial estimated memory to the basic system overhead of kdump, and obtains the peak dynamic memory requirement of kdump. Comparison and Suspension Module: Compares the reserved memory capacity with the peak dynamic memory demand. If the peak dynamic memory demand exceeds the reserved memory capacity, the original dump image and service startup sequence are suspended, and the command line append module is activated. Command line append module: Appends kernel boot parameters with a blacklist of target drivers to the kdump boot command line, including non-critical, redundant, high-memory-consuming drivers. Secure Dump Image Module: The dump image is reconstructed using the kdump dump component building tool to generate a secure dump image that completely excludes the non-critical redundant high memory consumption drivers; Suspension and Cancellation Module: Reloads the security dump image, cancels the suspension of the service startup sequence, and completes the loading of the kernel crash dump service kdump; Triggering module: When the kernel crash dump service kdump is triggered, it generates a physical memory state vmcore kernel dump file based on the secure dump image.

Images