Method, device and equipment for running simulation platform based on buddy memory management, and storage medium
By introducing buddy memory management into the optimistic parallel discrete event simulation platform, the running mode is automatically switched, the efficiency of state saving and restoration is optimized, the low efficiency of sparse writing to large-scale static data models in the existing technology is solved, and the performance and resource utilization of the simulation system are improved.
Patent Information
- Application Number
- CN202610476515.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-13
- Publication Date
- 2026-07-10
AI Technical Summary
Existing optimistic parallel discrete event simulation platforms suffer from low efficiency in state preservation and recovery when dealing with large-scale static data models with sparse writes, resulting in high memory and network bandwidth consumption. Existing incremental state preservation schemes are costly and complex to recover in long rollback and multi-node scenarios.
A simulation platform approach based on buddy memory management is adopted. By predicting the overhead of the running mode and automatically switching to a sparse memory model, a full state saving mode is implemented, and memory management is optimized by combining the buddy state pool and page fault signals.
It significantly reduces the overhead of state saving and rollback, improves the event processing speed and memory utilization efficiency of large-scale simulations, and maintains the ability to directly and fully restore the state.
Smart Images
Figure CN122363900A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of system simulation technology, and in particular to a simulation platform operation method, apparatus, device, and storage medium based on buddy memory management. Background Technology
[0002] In the field of optimistic parallel discrete event simulation (OPS), existing platforms such as ROOT-Sim (The ROme OpTimistic simulator, i.e., multi-core optimistic parallel discrete event simulation) typically employ a Periodic State Saving (PSS) mechanism by default. This mechanism requires copying and saving the complete runtime state of the logical process (LP) in memory at each checkpoint to ensure that the simulation system can roll back correctly in the event of a causal error. However, for many practical simulation models, especially large-scale network topology simulation models (such as LA-PDES, i.e., large-scale parallel discrete event simulation) and high-performance interconnection network simulation models (such as Dragonfly, i.e., the dragonfly topology network model), the state often contains large-scale static data such as topology tables and routing tables that remain unchanged for a long time after initialization, while the actual write operations during the simulation are extremely sparse. In such scenarios, PSS performs a full copy every time, which will cause a large number of unnecessary data copies in the distributed cluster environment, resulting in a significant increase in the time consumed by the state saving phase and a high consumption of memory and network bandwidth resources.
[0003] To mitigate this issue, existing technologies include Incremental State Saving (ISS) and hybrid PSS / ISS schemes. ISS only records memory pages modified since the last checkpoint, which can reduce the overhead of a single save. However, in distributed environments with long rollback distances and a large number of parallel nodes, the state recovery process may involve merging and reconstructing multiple incremental chains, resulting in high recovery time costs and implementation complexity.
[0004] Therefore, how to further optimize the state preservation and recovery efficiency of sparse writing and large-scale static data models while ensuring the correctness of optimistic parallel simulation remains a key technical challenge that needs to be overcome. Summary of the Invention
[0005] In view of this, the purpose of this invention is to provide a simulation platform operation method, apparatus, device, and storage medium based on buddy memory management, which can optimize the state preservation and recovery efficiency of sparse write and large-scale static data models. The specific solution is as follows: Firstly, this application discloses a simulation platform operation method based on buddy memory management, applied to a parallel discrete event simulation platform, including: The system acquires the running data of the target logic process in the current simulation cycle in the parallel discrete event simulation platform, and predicts the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model. The first running mode is a full state saving mode for the cycle. The second running mode is a full state saving mode based on the sparse memory model and the buddy system definition. Determine whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the current simulation cycle is in the first running mode, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold. If the target logic process meets the preset mode switching conditions, the running mode of the target logic process is switched to the second running mode. After allocating a corresponding buddy state pool for the target logic process, the memory management operation corresponding to the target logic process is executed based on the second running mode to complete the corresponding simulation operation.
[0006] Optionally, the step of obtaining the running data of the target logic process in the parallel discrete event simulation platform corresponding to the current simulation cycle, and predicting the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and a preset event overhead prediction model, includes: The write sparsity data, cost amplification factor, per-byte copy overhead, and average number of events processed in the current simulation cycle of the target logic process in the parallel discrete event simulation platform are obtained to obtain the running data of the target logic process. Based on the per-byte copy overhead, the number of events, and the preset event overhead prediction model, predict the first running overhead of the target logic process in the first running mode in the next simulation cycle; Based on the per-byte copy overhead, the write sparse data, the cost amplification factor, the number of events, and the preset event overhead prediction model, the second running overhead of the target logic process in the second running mode is predicted in the next simulation cycle.
[0007] Optionally, obtaining the write sparsity data, cost amplification factor, per-byte copy overhead, and average number of events processed in the current simulation cycle for the target logic process in the parallel discrete event simulation platform includes: The total time spent on checkpoint operations and the total number of bytes written are counted for the thread corresponding to the target logic process in the current simulation cycle, and the per-byte copy overhead of the target logic process is determined based on the total time spent on checkpoint operations and the total number of bytes written. The number of messages submitted and the time taken by the target logic process during the current simulation cycle when it is in a preset silent interval are counted to obtain the event processing throughput, and the average number of events processed in the current simulation cycle is determined based on the event processing throughput. The cost amplification factor is determined based on the actual time consumed by the target logic process at the checkpoint operation in the current simulation cycle. If the target logic process is in the first running mode, the write sparsity estimate of the target logic process in the current simulation cycle is obtained by using a preset probe window to obtain write sparsity data. If the target logic process is in the second running mode, the number of bytes in the inline record of the target logic process and the theoretical total number of bytes are obtained to obtain the write sparsity data.
[0008] Optionally, after allocating a corresponding buddy state pool for the target logical process, the method further includes: The buddy state pool is divided into several buddy blocks by page alignment using a buddy allocator, and a corresponding mapping relationship is established between the several buddy blocks and the target logical process; Set the preset page protection interface of the buddy state pool to read-only state so that when operating on the buddy block, a page fault exception signal is triggered, and the dirty flag of the buddy block is set to 1 based on the page fault exception signal.
[0009] Optionally, the step of performing memory management operations corresponding to the target logical process based on the second operating mode to complete the corresponding simulation operations includes: Determine whether the dirty flag of the buddy block corresponding to the target logical process is 1; If the dirty flag of the buddy block corresponding to the target logical process is 1, then it is determined that the buddy block has a history of modification operations or is being saved for the first time. Create an INLINE record for the buddy block and clear the dirty flag of the buddy block after the record is completed; the INLINE record contains the current allocation tree segment corresponding to the buddy block and the byte content of all allocated child blocks.
[0010] Optionally, the step of performing memory management operations corresponding to the target logical process based on the second operating mode to complete the corresponding simulation operations includes: Determine whether the dirty flag of the buddy block corresponding to the target logical process is 1; If the dirty flag of the buddy block corresponding to the target logical process is not 1, it is determined that the buddy block has not been modified, and a REF record is created for the buddy block; the REF record contains a reference to the most recent INLINE record.
[0011] Optionally, the step of performing memory management operations corresponding to the target logical process based on the second operating mode to complete the corresponding simulation operations includes: If the simulation operation is a data rollback operation, then the current record corresponding to the buddy block is checked; If the current record is an INLINE record, then copy the buddy data in the INLINE record to the corresponding buddy state pool location; If the current record is a REF record, then jump to the target record based on the reference relationship in the REF record, and copy the buddy data in the target record to the corresponding buddy state pool position.
[0012] Secondly, this application discloses a simulation platform running device based on buddy memory management, applied to a parallel discrete event simulation platform, comprising: The data acquisition module is used to acquire the running data of the target logic process in the parallel discrete event simulation platform in the current simulation cycle, and predict the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model; the first running mode is the full state saving mode of the cycle; the second running mode is the full state saving mode based on the sparse memory model and the buddy system definition. The condition judgment module is used to determine whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the current simulation cycle is in the first running mode, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold. The mode switching module is used to switch the running mode of the target logical process to the second running mode if the target logical process meets the preset mode switching conditions, and after allocating a corresponding buddy state pool for the target logical process, perform memory management operations corresponding to the target logical process based on the second running mode to complete the corresponding simulation operations.
[0013] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned simulation platform operation method based on buddy memory management.
[0014] Fourthly, this application discloses a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned simulation platform operation method based on buddy memory management.
[0015] As can be seen, in this application, the running data of the target logic process in the parallel discrete event simulation platform corresponding to the current simulation cycle is obtained, and the first running overhead of the target logic process in the next simulation cycle in the first running mode and the second running overhead in the second running mode are predicted based on the running data and the preset event overhead prediction model. The first running mode is a full state saving mode for the cycle. The second running mode is a full state saving mode based on the sparse memory model and the buddy system definition. It is determined whether the target logic process meets the preset mode switching conditions. The preset mode switching conditions are that the target logic process is in the first running mode in the current simulation cycle, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold. If the target logic process meets the preset mode switching conditions, the running mode of the target logic process is switched to the second running mode, and after allocating a corresponding buddy state pool for the target logic process, the memory management operation corresponding to the target logic process is executed based on the second running mode to complete the corresponding simulation operation. That is, under the premise of full state preservation, by predicting the running overhead of full state preservation and the full state preservation method in the next simulation cycle, the appropriate mode is automatically selected between SBF and traditional PSS according to the scenario. Thus, while maintaining the semantics of "state can be directly fully restored", the state preservation and rollback overhead of the distributed simulation system is significantly reduced, and the event processing speed and memory utilization efficiency of large-scale simulation are improved. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0017] Figure 1 This application discloses a flowchart of a simulation platform operation method based on buddy memory management. Figure 2 This is a schematic diagram of the simulation platform running device based on buddy memory management disclosed in this application; Figure 3 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation
[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0019] In optimistic parallel discrete event simulations, existing periodic full state saving requires complete copying of the logical process state at checkpoints. For models such as LA-PDES and Dragonfly, which contain a large amount of static data and have sparse writes, PSS generates a large number of invalid copies, resulting in high saving overhead and bandwidth consumption. Although incremental state saving and its hybrid schemes reduce single-time overhead, the recovery cost remains high and implementation is complex in scenarios with long rollbacks and multiple nodes. Therefore, this application will specifically introduce a simulation platform operation method based on buddy memory management, which can solve the above problems.
[0020] See Figure 1 As shown in the figure, this application discloses a simulation platform operation method based on buddy memory management, applied to a parallel discrete event simulation platform, including: Step S11: Obtain the running data of the target logic process in the current simulation cycle in the parallel discrete event simulation platform, and predict the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model; the first running mode is the full state saving mode of the cycle; the second running mode is the full state saving mode based on the sparse memory model and the buddy system definition.
[0021] In this embodiment, the present invention is aimed at a simulation platform that adopts an optimistic parallel discrete event simulation framework. Based on the existing ROOT-Sim state management module, a full state saving method based on sparse buddy pages is introduced, and an automatic switching module based on the LP dimension is added on top of it, so that SBF (i.e., the second running mode) and traditional PSS (i.e., the first running mode) can be adaptively selected according to runtime characteristics.
[0022] In this embodiment, obtaining the running data of the target logic process in the parallel discrete event simulation platform corresponding to the current simulation cycle, and predicting the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model, includes: obtaining the write sparsity data, cost amplification factor, per-byte copy overhead, and the average number of events processed in the current simulation cycle of the target logic process in the parallel discrete event simulation platform to obtain the running data of the target logic process; predicting the first running overhead of the target logic process in the next simulation cycle under the first running mode based on the per-byte copy overhead, the number of events, and the preset event overhead prediction model; and predicting the second running overhead of the target logic process in the next simulation cycle under the second running mode based on the per-byte copy overhead, the write sparsity data, the cost amplification factor, the number of events, and the preset event overhead prediction model. After each GVT (Global Virtual Time, a segment of the total simulation time; for example, if the total simulation time is 100, then 0 to 20, 20 to 50, and 50 to 100 might each be three GVT cycles; therefore, in this application, GVT is set as the simulation cycle), a mode evaluation and switching process is performed for each LP. For each LP, the currently estimated write sparsity (…) is used. ), cost multiplier ( ), per-byte copy overhead ( ) and the average number of events processed within the current checkpoint interval (which can be determined by ( (Calculate) The unit event cost for both modes.
[0023] The step of obtaining the write sparsity data, cost amplification factor, per-byte copy overhead, and average number of events processed in the current simulation cycle of the target logic process in the parallel discrete event simulation platform includes: calculating the total time spent on checkpoint operations and the total number of bytes written for the thread corresponding to the target logic process in the current simulation cycle, and determining the per-byte copy overhead of the target logic process based on the total time spent on checkpoint operations and the total number of bytes written; calculating the number of messages submitted and their time spent by the target logic process in the current simulation cycle when it is in a preset silent interval, to obtain the event processing throughput, and determining the average number of events processed in the current simulation cycle based on the event processing throughput; determining the cost amplification factor based on the actual time spent on checkpoint operations of the target logic process in the current simulation cycle; if the target logic process is in the first running mode, obtaining the estimated write sparsity value of the target logic process in the current simulation cycle using a preset probe window to obtain write sparsity data; if the target logic process is in the second running mode, obtaining the number of bytes in the inline record of the target logic process and the theoretical total number of bytes to obtain the write sparsity data.
[0024] Specifically, to achieve automatic switching between SBF and PSS, this invention continuously collects two types of statistics during simulation: thread-level global statistics and LP-level local statistics. To reduce noise, this invention uses Exponential Moving Average (EMA) to update the statistics. The thread-level statistics are maintained in the checkpoint management thread ackpt and updated after each GVT; the EMA window length is 16. The average cost per byte of checkpoint (…) ): Within a GVT cycle, the system calculates the total time elapsed (STATS_CKPT_TIME) and the total number of bytes written (STATS_CKPT_SIZE) for all LP checkpoints of this thread, and presses the following button at the end of GVT: ; Update the average copy cost per byte for subsequent estimation of the ideal memcpy time for PSS or SBF. Perform silent throughput ( When a thread is in a "silent interval" (no rollback or very few rollbacks), count the number of messages committed within that interval (STATS_MSG_SILENT) and the time elapsed (STATS_MSG_SILENT_TIME), and update this information at the end of GVT using a formula similar to EMA. ; Obtain the event processing throughput of this thread under "ideal conditions" to normalize checkpoint and rollback overhead. LP-level statistics (stored in the `auto_ckpt` structure of each LP, updated after each checkpoint). Write sparse samples ( For LPs using SBF, this invention records the number of INLINE bytes (inline_bytes) and the theoretical total number of full bytes (full_bytes) replicated in this checkpoint, and sets: ; This reflects the actual write ratio of the LP within the current GVT cycle. For LPs in PSS mode, this invention periodically opens a "probe window": temporarily arming write protection for the status page before a checkpoint, and obtaining the number of dirty bytes actually written in this cycle (dirty_bytes) at the end of the checkpoint. At this time, the following settings are configured: .
[0025] For each sample obtained, this invention updates the sparsity estimate according to the EMA (window length 32). ), and set the p_ready flag to true.
[0026] Sample of single checkpoint cost amplification factor ( This invention records the actual checkpoint time ckpt_time_ns. If the current mode is SBF, then ckpt_time_ns is directly regarded as the actual SBF save time; if the current mode is PSS and this is a probe window, then the SBF save time is estimated based on the dirty byte ratio. ), and set a lower limit of 1 nanosecond to avoid abnormal values. Then, compare the estimated SBF save time with the "ideal memcpy time" ( By taking the ratio, we obtain the cost amplification factor for this sample. Then update the long-term average using the EMA method. This is used to evaluate the amplification of additional overheads such as page protection, signal processing, and metadata maintenance relative to pure copying.
[0027] After collecting all the data, the unit event cost for both modes was calculated. If PSS is used, the unit event checkpoint cost is approximately ( If SBF is used, the cost per checkpoint is approximately ( ),in( This reflects page protection and additional signal overhead. It should be noted that the above formula only provides the calculation approach; in actual implementation, the `auto_ckpt` module completes the calculation in constant time.
[0028] Step S12: Determine whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the current simulation cycle is in the first running mode, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than the preset difference threshold.
[0029] In this embodiment, if the current mode is PSS, and the predicted SBF unit event cost is lower than PSS and the difference between the two exceeds a preset threshold (e.g., 10%), then the LP is switched to SBF mode in the next GVT cycle; conversely, if the current mode is SBF, and the estimated PSS cost is lower and the difference exceeds the threshold, then it is switched back to PSS in the next cycle. To avoid frequent jitter, this invention incorporates a hysteresis mechanism in the decision-making process, for example, requiring that the condition of "the other is better" be met for several consecutive GVT cycles before a true switch is made.
[0030] Step S13: If the target logic process meets the preset mode switching condition, the running mode of the target logic process is switched to the second running mode. After allocating a corresponding buddy state pool for the target logic process, the memory management operation corresponding to the target logic process is executed based on the second running mode to complete the corresponding simulation operation.
[0031] In this embodiment, when an LP switches from SBF back to PSS, the system removes page protection on the LP's state pool and changes subsequent checkpoints to simple block memcpy, while retaining the ability to "occasionally open a probe window" for continued refreshing. )and( Estimated value.
[0032] When a certain LP switches from PSS to SBF, the system allocates a buddy state pool for it, initializes the buddy allocation tree, sets read-only protection for each page after the first round of SBF checkpoint, and starts recording INLINE / REF according to SBF logic.
[0033] That is, after allocating a corresponding buddy state pool for the target logical process, the method further includes: dividing the buddy state pool into several buddy blocks using a buddy allocator with page alignment, and establishing a corresponding mapping relationship between the several buddy blocks and the target logical process; setting the preset page protection interface of the buddy state pool to a read-only state so that when operating on the buddy block, a page fault exception signal is triggered, and the dirty flag of the buddy block is set to 1 based on the page fault exception signal. In other words, in this invention, the state of each LP is carried by a contiguous memory pool, which is divided into several buddy blocks with page alignment by a buddy allocator. During runtime, the application still operates on the state memory through the ordinary malloc / free interface or the encapsulated ROOT-Sim allocation interface. The buddy allocator is responsible for maintaining the allocation tree (longest array) and the starting address and size of each buddy block. To accurately identify "buddy blocks modified since the last checkpoint" without modifying application code, this invention sets the state pool of the LP to read-only by calling the operating system's page protection interface (such as mprotect) after each SBF checkpoint. When a simulation event attempts to write to the page containing a buddy again, a page fault exception (such as the SIGSEGV signal) is triggered. The signal handling function finds the corresponding buddy block based on the trigger address, sets the "dirty flag" of that buddy to 1, and removes the read-only protection from the page containing that buddy, preventing subsequent writes from triggering the signal. In this way, a buddy block triggers the signal at most once between two checkpoints, thus limiting write tracing overhead to 0 (once per buddy per cycle).
[0034] During state preservation, this invention constructs a checkpoint stream consisting of several checkpoint records for each LP. Each record corresponds to a buddy block, and the record format includes: a pointer to the original buddy state, the record type, the offset to the next record, and optional data payload. Depending on whether the buddy is marked as "dirty," this invention employs one of the following two encoding methods for each buddy.
[0035] In a first specific embodiment, the step of performing memory management operations corresponding to the target logical process based on the second running mode to complete the corresponding simulation operation includes: determining whether the dirty flag of the buddy block corresponding to the target logical process is 1; if the dirty flag of the buddy block corresponding to the target logical process is 1, then determining that the buddy block has a history of modification operations or is being saved for the first time; creating an INLINE record for the buddy block, and clearing the dirty flag of the buddy block after recording is completed; the INLINE record contains the current allocation tree fragment and the byte content of all allocated sub-blocks corresponding to the buddy block. Specifically, if the buddy has been modified since the last INLINE, or is being saved for the first time, an INLINE record is created for it. The INLINE record contains the current allocation tree fragment and the byte content of all allocated sub-blocks of the buddy. After recording is completed, the dirty flag of the buddy is cleared, and read-only protection is reset for its corresponding page.
[0036] In a second specific embodiment, the execution of memory management operations corresponding to the target logical process based on the second running mode to complete the corresponding simulation operations includes: determining whether the dirty flag of the buddy block corresponding to the target logical process is 1; if the dirty flag of the buddy block corresponding to the target logical process is not 1, then it is determined that the buddy block has not been modified, and a REF record is created for the buddy block; the REF record contains a reference to the most recent INLINE record. If the buddy has not been modified since the last INLINE, a REF record is created for it. The REF record only contains a reference to the most recent INLINE record and does not copy any data. In this invention, a reference count (refcnt) is maintained for each INLINE record in the checkpoint structure. Each time a new REF record is added, the reference count of the INLINE record it points to is incremented by one for subsequent garbage collection.
[0037] In this embodiment, the execution of memory management operations corresponding to the target logical process based on the second running mode to complete the corresponding simulation operation includes: if the simulation operation is a data rollback operation, then checking the current record corresponding to the buddy block; if the current record is an INLINE record, then copying the buddy data in the INLINE record to the corresponding buddy state pool position; if the current record is a REF record, then jumping to the target record based on the reference relationship in the REF record, and copying the buddy data in the target record to the corresponding buddy state pool position. It should be noted that each LP checkpoint ends with a "termination sentinel" record, represented by a null pointer, with no actual payload. The overall checkpoint size is the sum of the lengths of all record headers and data payloads, aligned to 8 bytes. During recovery, this invention sequentially scans the records in the target checkpoint and processes them one by one against the current LP's buddy list: if an INLINE record is encountered, its buddy data is directly copied back to the corresponding state pool location; if a REF record is encountered, it jumps to the INLINE record it points to and copies its data back to the state pool. For buddies that do not have records in the checkpoint, this invention resets them to their default state through an initialization function. During recovery, all related pages are unprotected from read-only before writing and their protection is reset after writing, so that the next round of SBF can still track the write normally. To avoid the number of checkpoints from continuously increasing, this invention triggers a "fossil recycling" after GVT advancement: the system finds all checkpoints with timestamps earlier than GVT, decrements the reference count of the INLINE records they contain, and releases the memory space occupied by an INLINE record if its reference count drops to zero; at the same time, these old checkpoints are removed from the log list, realizing garbage collection of historical states.
[0038] In this embodiment, the running data of the target logic process in the parallel discrete event simulation platform corresponding to the current simulation cycle is obtained, and based on the running data and a preset event overhead prediction model, the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode are predicted respectively; the first running mode is a full state saving mode for the cycle; the second running mode is a full state saving mode based on the sparse memory model and the buddy system definition; it is determined whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the target logic process is in the first running mode in the current simulation cycle, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold; if the target logic process meets the preset mode switching conditions, the running mode of the target logic process is switched to the second running mode, and after allocating a corresponding buddy state pool for the target logic process, the memory management operation corresponding to the target logic process is executed based on the second running mode to complete the corresponding simulation operation. That is, under the premise of full state preservation, by predicting the running overhead of full state preservation and the full state preservation method in the next simulation cycle, the appropriate mode is automatically selected between SBF and traditional PSS according to the scenario. Thus, while maintaining the semantics of "state can be directly fully restored", the state preservation and rollback overhead of the distributed simulation system is significantly reduced, and the event processing speed and memory utilization efficiency of large-scale simulation are improved.
[0039] refer to Figure 2 The present application also discloses a simulation platform running device based on buddy memory management, applied to a parallel discrete event simulation platform, comprising: The data acquisition module 11 is used to acquire the running data of the target logic process in the parallel discrete event simulation platform in the current simulation cycle, and predict the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model; the first running mode is the full state saving mode of the cycle; the second running mode is the full state saving mode based on the sparse memory model and the buddy system definition. The condition judgment module 12 is used to determine whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the current simulation cycle is in the first running mode, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold. The mode switching module 13 is used to switch the running mode of the target logical process to the second running mode if the target logical process meets the preset mode switching conditions, and after allocating a corresponding buddy state pool for the target logical process, perform memory management operations corresponding to the target logical process based on the second running mode to complete the corresponding simulation operations.
[0040] In this embodiment, under the premise of full state preservation, by predicting the running overhead of full state preservation and the full state preservation method in the next simulation cycle, the appropriate mode is automatically selected between SBF and traditional PSS according to the scenario. Thus, while maintaining the semantics of "state can be directly fully restored", the state preservation and rollback overhead of the distributed simulation system is significantly reduced, and the event processing rate and memory utilization efficiency of large-scale simulation are improved.
[0041] In some specific embodiments, the data acquisition module 11 may specifically include: The data acquisition submodule is used to acquire the write sparsity data, cost amplification factor, per-byte copy overhead, and average number of events processed in the current simulation cycle of the target logic process in the parallel discrete event simulation platform, so as to obtain the running data of the target logic process. The first runtime determination unit is used to predict the first runtime of the target logic process in the first running mode in the next simulation cycle based on the per-byte copy overhead, the number of events and a preset event overhead prediction model. The second runtime determination unit is used to predict the second runtime of the target logic process in the second runtime mode in the next simulation cycle based on the per-byte copy overhead, the write sparse data, the cost amplification factor, the number of events, and the preset event overhead prediction model.
[0042] In some specific embodiments, the data acquisition submodule may specifically include: The overhead determination unit is used to calculate the total time spent on checkpoint operations and the total number of bytes written for the thread corresponding to the target logic process in the current simulation cycle, and to determine the per-byte copy overhead of the target logic process based on the total time spent on checkpoint operations and the total number of bytes written. The event count determination unit is used to count the number of messages submitted and the time consumed by the target logic process when it is in a preset silent interval during the current simulation cycle, so as to obtain the event processing throughput, and determine the average number of events processed in the current simulation cycle based on the event processing throughput. The cost amplification factor determination unit is used to determine the cost amplification factor based on the actual time consumed by the target logic process during the checkpoint operation in the current simulation cycle. The first write sparse data determination unit is used to obtain the write sparsity estimate of the target logic process in the current simulation cycle by using a preset probe window if the target logic process is in the first running mode, so as to obtain write sparse data. The second write sparse data determination unit is used to obtain the number of bytes and the theoretical total number of bytes in the inline record of the target logical process if the target logical process is in the second running mode, so as to obtain the write sparse data.
[0043] In some specific embodiments, the simulation platform running device based on buddy memory management may further include: The state pool partitioning module is used to divide the buddy state pool into several buddy blocks by page alignment using the buddy allocator, and to establish a corresponding mapping relationship between the several buddy blocks and the target logic process; The state pool setting module is used to set the preset page protection interface of the buddy state pool to a read-only state so that when the buddy block is operated, a page fault exception signal is triggered, and the dirty flag of the buddy block is set to 1 based on the page fault exception signal.
[0044] In some specific embodiments, the mode switching module 13 may specifically include: The first marking determination unit is used to determine whether the dirty flag of the buddy block corresponding to the target logical process is 1; The buddy block status determination unit is used to determine whether the buddy block has a history of modification operations or is being saved for the first time if the dirty flag of the buddy block corresponding to the target logical process is 1. The first record creation unit is used to create an INLINE record for the buddy block and clear the dirty mark of the buddy block after the record is completed; the INLINE record contains the current allocation tree fragment corresponding to the buddy block and the byte content of all allocated sub-blocks.
[0045] In some specific embodiments, the mode switching module 13 may specifically include: The second marking judgment unit is used to determine whether the dirty mark of the buddy block corresponding to the target logical process is 1; The second record creation unit is used to determine that the buddy block has not been modified if the dirty flag of the buddy block corresponding to the target logical process is not 1, and to create a REF record for the buddy block; the REF record contains a reference to the most recent INLINE record.
[0046] In some specific embodiments, the mode switching module 13 may specifically include: A record checking unit is used to check the current record corresponding to the buddy block if the simulation operation is a data rollback operation. The first data copying unit is used to copy the buddy data in the INLINE record to the corresponding buddy state pool position if the current record is an INLINE record. The second data copying unit is used to, if the current record is a REF record, jump to the target record based on the reference relationship in the REF record, and copy the buddy data in the target record to the corresponding buddy state pool position.
[0047] Furthermore, embodiments of this application also disclose an electronic device, Figure 3 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.
[0048] Figure 3 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 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 simulation platform operation method based on buddy memory management disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.
[0049] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 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.
[0050] 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.
[0051] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 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 buddy memory management-based simulation platform operation method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.
[0052] 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 simulation platform operation method based on buddy memory management. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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 for the purpose of helping to 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. A simulation platform operation method based on buddy memory management, characterized in that, Applications to parallel discrete event simulation platforms include: The system acquires the running data of the target logic process in the current simulation cycle in the parallel discrete event simulation platform, and predicts the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model. The first running mode is a full state saving mode for the cycle. The second running mode is a full state saving mode based on the sparse memory model and the buddy system definition. Determine whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the current simulation cycle is in the first running mode, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold. If the target logic process meets the preset mode switching conditions, the running mode of the target logic process is switched to the second running mode. After allocating a corresponding buddy state pool for the target logic process, the memory management operation corresponding to the target logic process is executed based on the second running mode to complete the corresponding simulation operation.
2. The simulation platform operation method based on buddy memory management according to claim 1, characterized in that, The step of acquiring the running data of the target logic process in the parallel discrete event simulation platform in the current simulation cycle, and predicting the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and a preset event overhead prediction model, includes: The write sparsity data, cost amplification factor, per-byte copy overhead, and average number of events processed in the current simulation cycle of the target logic process in the parallel discrete event simulation platform are obtained to obtain the running data of the target logic process. Based on the per-byte copy overhead, the number of events, and the preset event overhead prediction model, predict the first running overhead of the target logic process in the first running mode in the next simulation cycle; Based on the per-byte copy overhead, the write sparse data, the cost amplification factor, the number of events, and the preset event overhead prediction model, the second running overhead of the target logic process in the second running mode is predicted in the next simulation cycle.
3. The simulation platform operation method based on buddy memory management according to claim 2, characterized in that, The process of obtaining the write sparsity data, cost amplification factor, per-byte copy overhead, and average number of events processed in the current simulation cycle for the target logic process in the parallel discrete event simulation platform includes: The total time spent on checkpoint operations and the total number of bytes written are counted for the thread corresponding to the target logic process in the current simulation cycle, and the per-byte copy overhead of the target logic process is determined based on the total time spent on checkpoint operations and the total number of bytes written. The number of messages submitted and the time taken by the target logic process during the current simulation cycle when it is in a preset silent interval are counted to obtain the event processing throughput, and the average number of events processed in the current simulation cycle is determined based on the event processing throughput. The cost amplification factor is determined based on the actual time consumed by the target logic process at the checkpoint operation in the current simulation cycle. If the target logic process is in the first running mode, the write sparsity estimate of the target logic process in the current simulation cycle is obtained by using a preset probe window to obtain write sparsity data. If the target logic process is in the second running mode, the number of bytes in the inline record of the target logic process and the theoretical total number of bytes are obtained to obtain the write sparsity data.
4. The simulation platform operation method based on buddy memory management according to any one of claims 1 to 3, characterized in that, After allocating a corresponding buddy state pool for the target logical process, the process further includes: The buddy state pool is divided into several buddy blocks by page alignment using a buddy allocator, and a corresponding mapping relationship is established between the several buddy blocks and the target logical process; Set the preset page protection interface of the buddy state pool to read-only state so that when the buddy block is operated on, a page fault exception signal is triggered, and the dirty flag of the buddy block is set to 1 based on the page fault exception signal.
5. The simulation platform operation method based on buddy memory management according to claim 4, characterized in that, The step of performing memory management operations corresponding to the target logical process based on the second operating mode to complete the corresponding simulation operations includes: Determine whether the dirty flag of the buddy block corresponding to the target logical process is 1; If the dirty flag of the buddy block corresponding to the target logical process is 1, then it is determined that the buddy block has a history of modification operations or is being saved for the first time. Create an INLINE record for the buddy block and clear the dirty flag of the buddy block after the record is completed; the INLINE record contains the current allocation tree segment corresponding to the buddy block and the byte content of all allocated child blocks.
6. The simulation platform operation method based on buddy memory management according to claim 5, characterized in that, The step of performing memory management operations corresponding to the target logical process based on the second operating mode to complete the corresponding simulation operations includes: Determine whether the dirty flag of the buddy block corresponding to the target logical process is 1; If the dirty flag of the buddy block corresponding to the target logical process is not 1, it is determined that the buddy block has not been modified, and a REF record is created for the buddy block; the REF record contains a reference to the most recent INLINE record.
7. The simulation platform operation method based on buddy memory management according to claim 6, characterized in that, The step of performing memory management operations corresponding to the target logical process based on the second operating mode to complete the corresponding simulation operations includes: If the simulation operation is a data rollback operation, then the current record corresponding to the buddy block is checked; If the current record is an INLINE record, then copy the buddy data in the INLINE record to the corresponding buddy state pool location; If the current record is a REF record, then jump to the target record based on the reference relationship in the REF record, and copy the buddy data in the target record to the corresponding buddy state pool position.
8. A simulation platform running device based on buddy memory management, characterized in that, Applications to parallel discrete event simulation platforms include: The data acquisition module is used to acquire the running data of the target logic process in the parallel discrete event simulation platform in the current simulation cycle, and predict the first running overhead of the target logic process in the next simulation cycle under the first running mode and the second running overhead under the second running mode based on the running data and the preset event overhead prediction model; the first running mode is the full state saving mode of the cycle; the second running mode is the full state saving mode based on the sparse memory model and the buddy system definition. The condition judgment module is used to determine whether the target logic process meets the preset mode switching conditions; the preset mode switching conditions are that the current simulation cycle is in the first running mode, the first running overhead is greater than the second running overhead, and the difference between the first running overhead and the second running overhead is greater than a preset difference threshold. The mode switching module is used to switch the running mode of the target logical process to the second running mode if the target logical process meets the preset mode switching conditions, and after allocating a corresponding buddy state pool for the target logical process, perform memory management operations corresponding to the target logical process based on the second running mode to complete the corresponding simulation operations.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the simulation platform operation method based on buddy memory management as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, Used to store computer programs, which, when executed by a processor, implement the simulation platform running method based on buddy memory management as described in any one of claims 1 to 7.