Load monitoring method applied to game server, server and medium
Patent Information
- Application Number
- CN202611192896.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-07
- Publication Date
- 2026-10-16
AI Technical Summary
这种依据系统资源使用状况进行负载监测的方式属于对服务器运行状态的事后感知,即当监测到资源占用水平上升时,服务器内部已处于负载攀升阶段,导致负载调控措施的介入存在响应上的滞后,难以在负载即将形成的临界阶段预先进行调整,影响了游戏服务器在负载波动场景下维持处理节奏一致性的能力
[0007] This invention transforms the way server load is perceived from a monitoring logic perspective by using the player's command flow as the direct basis for load determination. After obtaining the command type label sequence and command arrival rate information, the corresponding baseline overhead weight is matched and queried in the command-overhead mapping table using the command type label as an index. This allows the load assessment process to measure the CPU cycle consumption of a single command without relying on operating system-level resource statistics, solely through command-level overhead pre-calibration. Load prediction processing based on command arrival rate information and baseline overhead weights generates a load prediction value before the command actually enters the logic frame for execution, enabling early perception of logic frame processing pressure and avoiding overload response delays caused by post-event detection. Based on the comparison between the load prediction value and the single-frame logic processing budget, a hierarchical instruction admission process is performed, moving non-critical instructions to a temporary queue while submitting only critical instructions to the logic frame execution flow. In overload conditions, priority is given to ensuring the timely processing of core game logic. Simultaneously, when the load prediction value falls back to a safe threshold, command packets are retrieved in batches from the temporary queue to resume processing, balancing the integrity of instruction processing with the smoothness of the player experience. During server idle periods, standard instruction sequences are proactively injected and actual execution time is collected. By comparing the deviation with the baseline overhead weight in the online self-calibration instruction-overhead mapping table, the pre-calibrated overhead measurement can adapt to the dynamic changes in the server operating environment and maintain the accuracy of load prediction results in long-term operation.
Smart Images

Figure CN122925149A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of load balancing, and more particularly to a load monitoring method, server, and medium for game servers. Background Technology
[0002] In existing technologies, game server load monitoring typically involves using performance monitoring tools to collect data on system resource usage during server operation. CPU utilization or memory consumption is used as the basis for judging the load status, and corresponding control measures are implemented when resource usage reaches a preset warning level. This method of load monitoring based on system resource usage is a reactive approach to server operation. When an increase in resource usage is detected, the server is already in a load-climbing phase, leading to a lag in the intervention of load control measures. It is difficult to make adjustments in advance when the load is about to reach a critical stage, affecting the game server's ability to maintain a consistent processing rhythm under fluctuating load scenarios. Summary of the Invention
[0003] This invention provides a load monitoring method, server, and medium for game servers.
[0004] In a first aspect, the present invention provides a load monitoring method for a game server, the method being applied to a server and comprising: At the beginning of the logical frame of the server's main loop, the accumulated player operation command stream in the current processing cycle is parsed to generate a command type label sequence and command quantity information associated with the command type label. Using the instruction type label in the instruction type label sequence as an index, a matching query is performed in the preset instruction-overhead mapping table to obtain the baseline overhead weight corresponding to each instruction type label. The baseline overhead weight represents a pre-calibrated measure of the number of CPU cycles consumed to process a single instruction of that type. Based on the instruction quantity information and the baseline overhead weight, load estimation is performed to generate a load estimate for the logic frame to be processed. The load estimate represents the predicted level of CPU cycle consumption within the logic frame to be processed. Based on the comparison between the load estimate and the single-frame logic processing budget, instruction packets in the current processing cycle are subject to instruction classification and admission processing. Instruction packets belonging to the non-critical instruction category are moved to the non-critical instruction temporary storage queue, while instruction packets belonging to the critical instruction category are submitted to the logic frame execution process. When the load estimate is detected to fall back to the preset safety threshold, instruction packets in the non-critical instruction temporary storage queue are retrieved in batches and restored for processing. During periods when the server is under idle load, standard instruction sequences are proactively injected into the logical frame execution process. The actual execution time of the standard instruction sequences is collected, and the deviation is compared with the baseline overhead weight of the corresponding instruction type label in the instruction-overhead mapping table. Based on the deviation comparison results, the baseline overhead weight is updated online through self-calibration.
[0005] Secondly, embodiments of the present invention provide a server, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the program to implement the steps in the above method.
[0006] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method.
[0007] This invention transforms the way server load is perceived from a monitoring logic perspective by using the player's command flow as the direct basis for load determination. After obtaining the command type label sequence and command arrival rate information, the corresponding baseline overhead weight is matched and queried in the command-overhead mapping table using the command type label as an index. This allows the load assessment process to measure the CPU cycle consumption of a single command without relying on operating system-level resource statistics, solely through command-level overhead pre-calibration. Load prediction processing based on command arrival rate information and baseline overhead weights generates a load prediction value before the command actually enters the logic frame for execution, enabling early perception of logic frame processing pressure and avoiding overload response delays caused by post-event detection. Based on the comparison between the load prediction value and the single-frame logic processing budget, a hierarchical instruction admission process is performed, moving non-critical instructions to a temporary queue while submitting only critical instructions to the logic frame execution flow. In overload conditions, priority is given to ensuring the timely processing of core game logic. Simultaneously, when the load prediction value falls back to a safe threshold, command packets are retrieved in batches from the temporary queue to resume processing, balancing the integrity of instruction processing with the smoothness of the player experience. During server idle periods, standard instruction sequences are proactively injected and actual execution time is collected. By comparing the deviation with the baseline overhead weight in the online self-calibration instruction-overhead mapping table, the pre-calibrated overhead measurement can adapt to the dynamic changes in the server operating environment and maintain the accuracy of load prediction results in long-term operation. Attached Figure Description
[0008] Figure 1 This is a schematic diagram illustrating the implementation process of a load monitoring method for game servers provided in an embodiment of the present invention.
[0009] Figure 2 This is a schematic diagram of the composition structure of a load monitoring device provided in an embodiment of the present invention.
[0010] Figure 3 This is a schematic diagram of a server hardware entity provided in an embodiment of the present invention. Detailed Implementation
[0011] This invention provides a load monitoring method for game servers, which can be executed by the processor of the server (game server). Figure 1 This is a schematic diagram illustrating the implementation process of a load monitoring method for game servers provided in an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes the following steps S100~S500: Step S100: At the beginning of the logical frame of the server's main loop, perform instruction type parsing on the player operation instruction stream accumulated in the current processing cycle to generate an instruction type label sequence and instruction quantity information associated with the instruction type label.
[0012] The server main loop is the core of the game server process that drives the periodic scheduling of game world state updates and synchronization. Each complete execution cycle is called a logical frame. The logical frame start phase refers to the execution window after the main loop finishes sending the result of the previous frame and before the execution of the new frame's game logic calculation begins. The player operation command stream is a set of player operation data packets collected from each client via the network interface and temporarily stored in the memory receive buffer during the time interval between the end of the previous logical frame and the start of the current logical frame. Command type parsing is the process of extracting command type tags that identify the command category from each binary data packet in the player operation command stream, according to the communication protocol format pre-agreed between the client and the server. The command type tag sequence is an ordered list formed by arranging the extracted command type tags in the order in which each command packet appears during the parsing process. The command quantity information associated with the command type tag is a mapping relationship established between the tag and the number of occurrences after counting and accumulating the entries with the same tag value in the sequence.
[0013] During the static initialization phase of the game server process, the memory receive buffer is constructed as a circular buffer, internally maintaining a head-of-queue read pointer and a tail-of-queue write pointer. The network interface thread continuously writes client operation data packets to the slot pointed to by the tail-of-queue write pointer and increments the pointer. When the main loop enters the logical frame start phase, it reads in batches all player operation command streams accumulated since the end of the previous frame from the head-of-queue read pointer. The read binary byte sequence is passed to the command pre-parsing module, which integrates a command format parser based on a deterministic finite state automaton. The parser uses the command start identifier magic number agreed upon in the protocol as the state transition trigger condition, initially in a waiting start identifier state; when a matching magic number pattern appears in the byte stream, the state machine transitions to the command type label reading state, extracting the binary value of the command type label according to the fixed offset and fixed length specified in the protocol. Subsequently, the state machine enters the command length field reading state, obtains the payload bytes of the command packet, calculates the position offset of the next command start identifier in the byte stream, and the state machine transitions back to the waiting start identifier state, thus looping until all player operation command streams have been processed.
[0014] During packet-by-packet parsing, the instruction pre-parsing module maintains an associated counting mapping structure with integer values of instruction type labels as keys and occurrence counts as values, implemented using an open-addressable hash table. Whenever the parser extracts an instruction type label, the module calculates the hash bucket index using that label value and performs a lookup: if an entry for that label already exists in the target bucket, the count is atomically incremented; if the target bucket is empty, a new entry is created in that bucket and the count is initialized to 1. After all player operation instruction streams have been parsed, the module iterates through all occupied buckets in the hash table, extracts the keys sequentially to form an instruction type label sequence, and pairs the keys with the count values to form the instruction count information associated with the instruction type label.
[0015] Step S200: Using the instruction type label in the instruction type label sequence as an index, perform a matching query in the preset instruction-overhead mapping table to obtain the baseline overhead weight corresponding to each instruction type label. The baseline overhead weight represents a pre-calibrated measure of the number of CPU cycles consumed in processing a single instruction of that type.
[0016] The instruction-overhead map is a lookup table pre-built during the static initialization phase, storing the mapping relationship from instruction type labels to baseline overhead weights. The baseline overhead weight is a fixed reference value obtained by independently and repeatedly testing the instruction processing function of a single instruction in a typical hardware environment, and then calculating the average CPU cycle consumption. CPU cycles are the basic unit of time corresponding to one complete oscillation cycle of the processor clock signal.
[0017] The server's main loop uses each tag in the instruction type tag sequence as a query key to perform a matching query in the instruction-cost mapping table. The query logic compresses the tags into fixed-length binary digests using cyclic redundancy check hardware instructions, and searches for valid entries with the same digest in the mapping table using open addressing. When a match is successful, the corresponding baseline cost weight is read; when a match fails, a preset conservative baseline cost weight burned into read-only memory is used as a backoff value, and a mapping missing event record is generated. After all tags have been queried, the baseline cost weight set is collected in the weight temporary storage buffer.
[0018] In one possible implementation, step S200 includes the following steps S210 to S260: Step S210: Store the instruction-overhead mapping table in a memory region aligned with the processor cache line. Each entry in the instruction-overhead mapping table contains a fixed-length hash digest of the instruction type label, a baseline overhead weight, and a status flag bit used to mark the validity of the entry. The storage width of the entry is padded to an integer multiple of the processor cache line length.
[0019] A processor cache line is the smallest contiguous block of bytes for a single data transfer between the processor cache and main memory. In a multi-level cache hierarchy, the cache line size of the first-level data cache is typically 64 bytes. Processor cache line alignment means that the starting address and internal element boundaries of a data structure are planned in units of cache line size, ensuring that a single entry can be fully loaded in a single cache line fill operation, preventing a single entry from spanning two cache line boundaries. The memory layout of an entry contains three fields: a fixed-length hash digest (32 bits wide), output by performing a polynomial modulo 2 division operation on the hexadecimal string representation of the instruction type label using a standard 32-bit generator polynomial; a base overhead weight (32-bit unsigned integer); and an 8-bit status flag (0 for invalid, 1 for valid). These three fields total 9 bytes, and the total width of the entry is 64 bytes by appending 55 bytes of no-operation padding.
[0020] In one possible implementation, step S210 includes the following steps S211 to S216: Step S211: During the static initialization phase of the game server process startup, a memory region with a size equal to the product of the expected capacity of the instruction-overhead mapping table and the width of a single table entry is allocated through the memory alignment allocator, and the starting address of the requested memory region is aligned to the boundary of the processor's L1 cache line length.
[0021] The static initialization phase is the initialization window after the program loader completes image mapping and dynamic linking, and before the main loop starts. The memory alignment allocator calls the alignment memory allocation function conforming to the portable operating system interface standard. This function searches for or requests contiguous virtual memory in the process heap manager that meets the requested size and whose starting address is an integer multiple of the processor's L1 cache line length via system calls. The expected capacity of the instruction-overhead mapping table is determined by multiplying the total number of instruction types enumerated by the redundancy expansion factor. The width of a single table entry is a fixed number of bytes equal to the cache line length, guaranteed by padding in step S210. The memory alignment allocator calculates the product of the expected capacity and the width of a single table entry as the total number of requested bytes. If the existing free block does not meet the alignment requirements, it requests a larger memory block, adjusts the internal offset, and returns the starting address that meets the boundary alignment requirements.
[0022] Step S212: Divide the memory region into multiple cache line segments according to the processor cache line length. Each cache line segment stores all fields of a single table entry. When filling the table entry fields, if the total width of the fields does not fill a cache line segment, the end of the table entry is extended to the end address of the cache line segment by appending no-operation bytes. A table entry is prohibited from spanning two cache line segments.
[0023] Starting from the memory region start address obtained in step S211, the memory region is divided into zeroth cache line segments, first cache line segments, and so on, with the processor's L1 cache line length as a fixed step size, until the entire memory region is covered. Each cache line segment stores the binary representation of three fields for a single entry: a fixed-length hash digest, a base overhead weight, and a status flag. When the actual total width of the three fields is less than the length of one cache line segment, zero-valued bytes are appended consecutively to the end of the fields until the space occupied by the entry extends to the end address of the cache line segment. The start address of the entry is forcibly aligned to the start address of the cache line segment, and all fields and padding bytes fall within the address range of the same cache line segment, ensuring from a physical address layout perspective that an entry never crosses the boundary of two cache line segments.
[0024] Step S213: Attach a cache line write-back control field to each cache line segment in the memory region. The cache line write-back control field is used to indicate the ownership status of the cache line segment in the processor cache coherence protocol. When an entry is updated, the modified entry and the cache line write-back control field are written back to memory together by executing a storage instruction with write-back semantics.
[0025] The cache line write-back control field is metadata for each cache line segment, with a bit width of 2 or 4 bits. It encodes the ownership state defined in the cache coherence protocol: modified, exclusive, shared, and invalid. This field is stored in reserved bytes at the end of the cache line segment or in a separate array of control information. When the baseline overhead weight field needs to be modified in the table entry update path, the processor core first acquires exclusive ownership of the cache line segment through an atomic instruction. After modification, it executes a store instruction with write-back semantics. This instruction writes the modified complete table entry data, along with the updated cache line write-back control field, to the corresponding memory location according to the state transition rules of the coherence protocol. This makes the update visible in global memory order and downgrades the cache line segment state from exclusive modified to shared, allowing other cores to read it.
[0026] Step S214: Insert a processor data prefetch instruction into the table entry read path. The data prefetch instruction uses the cache line segment address corresponding to the starting slot index as the operand, loads the cache line segment from main memory to the processor's last-level cache in advance, and marks it as a shared state.
[0027] The table lookup path refers to the instruction execution sequence from determining the probe start slot index to actually accessing the table entry data. Processor data prefetch instructions are non-blocking data prefetch hints provided by the processor, allowing software to inform the processor in advance of the memory address to be accessed. The processor initiates asynchronous data transfer in the background without blocking the current instruction stream. In the table lookup process, the compiler or assembly code inserts a data prefetch instruction at the appropriate position in the table entry lookup path. The operand is the cache line segment start address obtained by multiplying the probe start slot index by the width of a single table entry and adding the base address of the memory region. After resolving this address, the prefetch hardware unit generates a prefetch request, loads the cache line segment from main memory or the previous cache to the last cache, and marks it as shared in the cache coherence protocol. This allows multiple processor cores to share a copy of the data in the cache line segment in read-only mode, and subsequent table entry read operations obtain data directly from the last cache with extremely low latency.
[0028] Step S215: In the table entry update path, before modifying the baseline overhead weight in the table entry, execute an atomic swap instruction to acquire exclusive ownership of the cache line, change the state of the target cache line segment from the shared state to the exclusive modification state, and after the modification is completed, downgrade the cache line segment to the shared state through a write-back operation.
[0029] The table entry update path is the instruction execution sequence from locating the target table entry to completing the data write when a server process needs to modify the baseline overhead weight of an existing entry in the mapping table. The atomic swap instruction, guaranteed by the processor hardware to be uninterruptible, accepts a memory address and a register operand, swaps the current value at the memory address with the register value, and returns the original value at the memory address. The atomic swap instruction used in this step incorporates cache coherence state transition semantics: the processor core issues an atomic swap request to the cache line segment containing the target table entry. The cache coherence hardware first invalidates all copies of this cache line segment in the caches of all other cores, changing the state of the cache line segment in the local cache from shared to exclusive modification. Then, in the exclusive modification state, the atomic swap of data is performed, writing the new baseline overhead weight to the table entry. Immediately after modification, a write-back operation is performed, flushing the contents of the cache line segment in the exclusive modification state to main memory and downgrading its state in the local cache to shared.
[0030] Step S216: Allocate a hardware performance monitoring event counter for each cache line segment in the memory region to record the frequency of cache miss events and remote cache access events occurring in the cache line segment. When the frequency of cache miss events exceeds a preset frequency limit, relocate the entry corresponding to the cache line segment and move it to an empty slot to reduce cache line ping-pong transfer between multiprocessor cores.
[0031] The hardware performance monitoring event counter is a programmable hardware counter integrated into the processor performance monitoring unit. Each counter can be bound to a specific microarchitecture event for cumulative counting. During the initialization phase, the server allocates a dedicated hardware performance monitoring event counter for each cache line segment in the instruction-overhead mapping table memory area, configured to count both cache miss events and remote cache access events simultaneously. The preset frequency limit is a positive integer threshold configured by the system and adjusted according to the number of processor cores and cache hierarchy characteristics. When the frequency of cache miss events in a cache line segment exceeds this limit within a preset time window, it is determined that the cache line segment is experiencing a cache line ping-pong problem between multiple cores, i.e., multiple cores frequently perform exclusive reads and writes to the same cache line segment, causing data to be repeatedly invalidated and migrated between cores. At this time, a free slot with an invalid status flag is found in the mapping table, the table entry data in the problematic cache line segment is completely copied there, the status flag of the original entry is updated to invalid, and the status flag of the new slot is updated to valid, completing the table entry relocation to disperse multi-core access conflicts.
[0032] Step S220: Perform deduplication traversal on the instruction type label sequence, and temporarily store the instruction type label that appears for the first time during the traversal into the instruction label deduplication temporary register. After the traversal is completed, use all the instruction type labels temporarily stored in the instruction label deduplication temporary register as the set of independent instruction type labels for the current processing cycle.
[0033] The instruction type tag sequence is an ordered list output from step S100, containing duplicate tags because multiple players may send the same type of instruction within the same processing cycle. Deduplication traversal involves sequentially accessing each element from beginning to end according to the sequence's order, selecting only the first occurrence of a tag, and skipping subsequent occurrences of the same tag. The instruction tag deduplication buffer is a pre-allocated temporary storage area within the logical frame control block, employing a linear array structure and equipped with a fixed-length hash bitmap as an auxiliary structure for existence checks. During traversal, each instruction type tag in the sequence is read sequentially, a fast hash function is applied to the tag value to calculate the hash value, and the bit index is obtained by modulo the bitmap length. If the corresponding bit in the bitmap is 0, it indicates the first occurrence; the bit is set to 1, and the tag is appended to the end of the deduplication buffer. If the bit is already 1, it indicates a duplicate tag, which is discarded, and the next tag is processed. After traversal, all tags temporarily stored in the deduplication buffer constitute an independent set of instruction type tags.
[0034] Step S230: For each independent instruction type label in the independent instruction type label set, call the processor's built-in cyclic redundancy check hardware instruction to process the string representation of the independent instruction type label, read the fixed-length binary digest output by the hardware instruction, and perform a bitwise AND operation between the fixed-length binary digest and the binary mask of the total number of slots in the instruction-overhead mapping table to obtain the probe starting slot index.
[0035] The processor's built-in Cyclic Redundancy Check (CRC) hardware instruction is a single-instruction unit (SIU) that uses dedicated digital circuitry to calculate CRC codes. It performs a polynomial modulo-2 division of the input operands within a fixed number of clock cycles. During execution, the 32-bit unsigned integer value of the independent instruction type label is first converted to a fixed-length hexadecimal string, with each 4 bits mapped to a hexadecimal digit character. The memory address and byte length of this string are used as input parameters to call the CRC hardware instruction. The instruction's internal linear feedback shift register array processes each byte of the string bit by bit using a standard 32-bit generator polynomial. After all bytes have been processed, the latched state value in the register is the fixed-length binary digest, which is output to a general-purpose register. The total number of slots in the instruction-overhead mapping table is initialized to a power of 2, and its binary mask is the total number of slots minus 1, with the least significant bit consisting of a series of 1s. The fixed-length binary digest and the binary mask are fed into the arithmetic logic unit (ALU) to perform a bitwise AND operation, equivalent to a modulo operation. The result is the probe's starting slot index, ranging from 0 to the total number of slots minus 1.
[0036] Step S240: Starting from the probe start slot index, read the status flag bit of the corresponding slot in the instruction-overhead mapping table. If the status flag bit indicates that the slot is valid, perform a bit-by-bit equality comparison between the fixed-length hash digest of the instruction type label stored in the slot and the fixed-length binary digest corresponding to the current independent instruction type label. If the bits are completely equal, load the baseline overhead weight in the slot into the processor general-purpose register.
[0037] The byte offset of the target entry within the instruction-overhead mapping table memory region is obtained by multiplying the starting slot index by the width of a single entry. This offset is then added to the base address of the memory region to calculate the absolute memory address of the target entry. A one-byte status flag value is read from this address plus the offset from the status flag field. If the status flag equals an invalid status code, it indicates that there is no valid data in the slot, and the process proceeds to step S250 to perform the probe offset. If the status flag equals a valid status code, the stored digest value is read from the fixed-length hash digest field of the slot and loaded into the first general-purpose register. The fixed-length binary digest corresponding to the independent instruction type label calculated in step S230 is loaded into the second general-purpose register. A processor XOR instruction is executed to perform a bit-by-bit XOR operation on the two registers: if corresponding bits are the same, the result bit is 0; otherwise, the result bit is 1. The zero flag in the processor status register is checked. If the zero flag is set, it indicates that all bits of the XOR result are 0, and the two digests are completely equal bit-by-bit, indicating a successful match. A load instruction is executed from the base overhead weight field of the slot to read the weight into the processor general-purpose register. If the zero flag is not set, the match fails, and proceed to step S250.
[0038] Step S250: If the bit-by-bit equality comparison result is not equal, then perform a constant step size offset on the probe start slot index to obtain the next probe slot index, and jump to the operation of reading the corresponding slot status flag bit. When the number of probes reaches the preset probe limit, load the preset conservative baseline overhead weight into the processor general-purpose register, and generate a mapping missing event record for the current independent instruction type label.
[0039] The constant step offset adds a fixed prime number, coprime to the total number of slots, to the current probe slot index. The next probe slot index is obtained by taking the modulo of the sum of the two values (total number of slots), ensuring the probe sequence evenly covers all slots in the mapping table. The preset probe limit is a system configuration parameter that restricts the maximum number of probes for a single tag. The preset conservative baseline overhead weight is a high constant pre-programmed into the processor's read-only static memory, determined based on the worst-case instruction processing overhead. The mapping missing event record is a data structure containing a fixed-length binary digest, a timestamp count, and a snapshot of the slot occupancy percentage.
[0040] If the bit-by-bit equality comparison result in step S240 is not equal, calculate the index of the next probe slot and increment the probe count. If the probe count has not reached the preset probe limit, jump to step S240 to read the corresponding slot status flag bit and continue probing; if the probe count has equaled the preset probe limit, stop probing, read the preset conservative baseline overhead weight from the read-only static storage area and load it into the processor general-purpose register, and construct a mapping missing event record.
[0041] In one possible implementation, in step S250, when the number of probes reaches a preset probe limit, a preset conservative baseline overhead weight is loaded into the processor general-purpose register, and a mapping missing event record for the current independent instruction type label is generated, including the following steps S251 to S256: Step S251: When starting to perform a mapping table lookup on the independent instruction type label, initialize a probe count register and set the count register to 0. Each time the jump to the next probe slot is performed, increment the value of the probe count register by 1 and compare the value with the preset probe limit.
[0042] At the entry point of the mapping table lookup, a data transfer instruction is executed to move the immediate value 0 into the probe count register, completing the initialization. Whenever the constant step offset logic in step S250 calculates the next probe slot index and prepares to jump, an increment instruction is first executed on the probe count register to increase its current value by 1. Then, a comparison instruction is executed to compare the register value with the preset probe upper limit immediate value loaded from memory. The comparison result updates the condition code flag in the processor status register, allowing subsequent conditional branch instructions to determine the program flow.
[0043] Step S252: When the value of the probe count register is equal to the preset probe limit, temporarily block the mapping query of the independent instruction type label, retrieve the pre-programmed conservative baseline overhead weight from the processor's built-in read-only static storage area, and load the conservative baseline overhead weight into the processor's general-purpose register.
[0044] In step S251, when the comparison instruction determines that the current value of the probe count register is equal to the preset probe upper limit, the conditional branch instruction jumps to the conservative weight loading processing branch. In this branch, a query termination flag variable is set to prevent further probes to subsequent slots. The processor's built-in read-only static memory area is a storage area written during manufacturing or firmware burning and cannot be modified during operation. A load instruction using the absolute address of the preset conservative baseline overhead weight in this area as the source operand reads the weight and writes it to a specified processor general-purpose register.
[0045] Step S253: After loading the conservative baseline overhead weights into the processor general-purpose registers, construct a mapping missing event record. The mapping missing event record includes a fixed-length binary digest of the current independent instruction type label, the current timestamp count, and a snapshot of the slot occupancy ratio of the instruction-overhead mapping table at the current moment.
[0046] The fixed-length binary digest generated in step S230 is read from the query context and copied to the fixed-length binary digest field of the newly allocated memory region for mapped missing event records. An instruction to read the timestamp counter is executed to obtain the current count value, which is then written to the current timestamp count field of the event record. The slot occupancy ratio snapshot is calculated by traversing the status flag bits of all slots in the instruction-overhead mapping table: for each slot, the status flag bit is checked to see if it is a valid status code; an accumulator counter is used to count the number of valid slots; the result is divided by the total number of slots to obtain the ratio value, which is then written to the corresponding field of the event record.
[0047] Step S254: Deliver the mapped missing event record to the asynchronous log recording thread through the lock-free single producer single consumer queue. The asynchronous log recording thread serializes the mapped missing event record and writes it to the persistent storage device, and increments the global missing counter.
[0048] The lock-free, single-producer, single-consumer queue consists of a fixed-size circular buffer, a head-of-queue read pointer, and a tail-of-queue write pointer. The producer role is played by a thread executing the server's main loop, while the consumer role is played by an independently running asynchronous logging thread. After the main loop thread constructs the mapped missing event records, it pre-reserves a write slot in the circular buffer by performing an atomic acquire-increment operation on the tail-of-queue write pointer. It then uses a normal storage instruction to write the memory block pointer of the event record to the slot, and subsequently performs a storage release barrier operation to ensure the data is visible to the consumer thread. When the asynchronous logging thread detects a discrepancy between the head-of-queue read pointer and the tail-of-queue write pointer in its main loop, it reads the event record pointer from the slot pointed to by the head-of-queue read pointer and moves the read pointer forward. It then writes the fixed-length binary digest, current timestamp count, and slot occupancy snapshot contained in the event record into persistent storage in a serialized format, and performs an atomic increment operation on the global missing counter.
[0049] Step S255: After triggering the missing mapping event record, query the instruction-overhead mapping table to see if there is an empty slot with the status flag indicating invalid. If there is an empty slot, bind the slot index of the empty slot to the fixed-length binary digest of the current independent instruction type label, write the conservative baseline overhead weight to the baseline overhead weight field of the slot, and set the status flag to valid.
[0050] Perform a linear scan of all slots in the instruction-overhead mapping table, starting from slot zero and incrementing the index to read the status flag bit slot by slot, searching for a free slot where the status flag bit equals an invalid status code. Upon finding a free slot, immediately stop scanning and record the slot index. Calculate the table entry base address using this slot index, write the fixed-length binary digest corresponding to the current independent instruction type label into the fixed-length hash digest field of the table entry, write the conservative baseline overhead weight loaded in step S252 into the baseline overhead weight field, and write the valid status code into the status flag field. If no invalid slot is found during the entire scan, it indicates that the mapping table is full, and the current addition operation is abandoned.
[0051] Step S256: After writing the conservative baseline cost weight to the free slot, report a mapping table expansion prompt containing the current independent instruction type label and the allocated slot index to the server management interface, and reset the query process for the independent instruction type label to reload the baseline cost weight from the free slot.
[0052] The server management interface is an internal call interface provided by the game server, which can be implemented by sending console logs to the management terminal and remote procedure call messages to the monitoring service process. The mapping table expansion prompt includes the complete value of the independent instruction type label newly added to the mapping table and its allocated free slot index. After reporting is completed, the probe count register of the current independent instruction type label is cleared, the query state is reset to the initial state, and the read operation of step S240 is re-executed with the free slot index of the recently written data as the target. The conservative baseline overhead weight value just written is loaded from the baseline overhead weight value field of that slot into the processor general-purpose register, ensuring that the weight value returned by this query is consistent with the current content stored in the mapping table.
[0053] Step S260: Store the baseline overhead weights in the processor's general-purpose registers into a weight temporary storage buffer associated with the current independent instruction type label. After all independent instruction type label sets have been processed, use the baseline overhead weights stored in the weight temporary storage buffer as the baseline overhead weight set corresponding to the instruction type label sequence.
[0054] The weight buffer is a contiguous temporary memory space allocated within the logical frame control block. It can hold several entries equal to the upper limit of the independent instruction type label set, with each entry containing a pair of instruction type labels and corresponding baseline overhead weights. After the server main loop successfully matches and obtains the baseline overhead weight in step S240, or obtains the weight through the conservative path in step S250, or obtains the weight through reloading in step S256, it executes a store instruction to write the value in the processor's general-purpose register into the slot allocated for the current label in the weight buffer, and simultaneously writes the label value into the label field of the same slot. After all independent instruction type labels have been processed, the content stored in the weight buffer is the baseline overhead weight set.
[0055] Step S300: Perform load estimation processing based on instruction quantity information and baseline overhead weights to generate a load estimation value for the logic frame to be processed. The load estimation value represents the predicted level of CPU cycle consumption within the logic frame to be processed.
[0056] The load estimation process involves weighted summing of the frequency of each instruction type in the instruction quantity information generated in step S100 and the corresponding baseline overhead weights in the baseline overhead weight set generated in step S200. This summation is combined with the coupling adjustment amount of the instruction type combination and the historical deviation correction amount to calculate the total number of CPU cycles expected to be consumed in completing all instruction processing for the current logic frame. The load estimation value is an integer value in CPU cycles output by this calculation process, reflecting the expected level of processor cycle resources consumed in executing game logic updates under the current player operation instruction configuration.
[0057] In one possible implementation, step S300 includes the following steps S310 to S360: Step S310: Perform a bitwise XOR operation between the current count value of the processor's timestamp counter and the historical count value when the previous logical frame was completed, extract the continuous bit segment with the highest bit change rate, and input the bit segment to the entropy source input terminal of the processor's built-in hardware random number generator to provide entropy that depends on the processor clock jitter for instruction jitter smoothing.
[0058] The processor's timestamp counter is a counter that monotonically increases at the clock frequency after the processor is powered on and reset. The historical count value at the completion of the previous logical frame is a snapshot of the timestamp counter read and stored in the logical frame control block at the end of each logical frame execution. The bitwise XOR operation performs an XOR logical operation on each corresponding bit of the current count value and the historical count value. The consecutive bit segment with the highest bit change rate is selected after analyzing the flip frequency of adjacent bit values within each consecutive bit segment from the XOR result. The processor's built-in hardware random number generator contains an entropy source input port, allowing software to inject external entropy values to improve the unpredictability of random number output. The binary value of the selected high bit change rate segment is written to the entropy source input port. The hardware random number generator mixes it with the internal physical entropy source signal and updates the entropy pool state. The subsequently read random numbers fully mix the processor clock jitter information and are used for jitter injection in the sliding window averaging process of step S320.
[0059] Step S320: For the instruction count of each instruction type label in the instruction count information, process it using a sliding window average. The sliding window average takes the increment of the previous window average result and the new sample of the current window as input, outputs the updated window average result, and latches the result into the window average result register.
[0060] For example, a hardware-implemented sliding window averaging circuit, integrated within the server's main processor chip or implemented via a field-programmable gate array (FPGA), operates based on an incremental recursive formula for the sliding window average: the new window average equals the old window average plus the quotient of the new sample value divided by the window length, minus the quotient of the oldest sample value divided by the window length. This circuit includes a window averaging result register, a window sample buffer register array, and dedicated arithmetic data paths for performing division and addition / subtraction. For each instruction type tag, the number of instructions in the current frame is used as the new sample. The oldest sample in the window is read from the historical record circular buffer, and the window average result read from the previous cycle is used as historical input, fed into the three input latches of the sliding window averaging circuit. The internal arithmetic data path calculates the updated window average result according to the recursive formula, sends it out through the output latch, and latches it into the window average result register corresponding to that tag. The instruction count processed by the sliding window averaging can filter out instantaneous spikes and occasional fluctuations in the player's operation frequency.
[0061] Step S330: Send the result in the window average result register and the baseline overhead weight of the corresponding instruction type label to the two source operand channels of the processor vector multiplication unit, respectively, and start the vector multiplication unit to perform parallel multiplication and accumulation operation to obtain the cycle consumption contribution of a single type of instruction.
[0062] The processor vector multiplication unit is the execution functional unit that performs single-instruction multiple-data parallel multiplication operations. Source operand channel one and source operand channel two are two independent vector data paths, each with a width equal to the width of the vector register. The window average results of each instruction type label are batch-loaded into the first vector register and connected to source operand channel one. The corresponding baseline overhead weights are batch-loaded into the second vector register and connected to source operand channel two. Vector integer multiplication instructions are issued to the vector multiplication unit. Multiple internal parallel multiplier arrays operate simultaneously, each multiplier array responsible for one data channel. The window average result of the corresponding channel is multiplied by the baseline overhead weight, and the result is output to the corresponding channel of the destination vector register, representing the single-instruction cycle consumption contribution for each instruction type.
[0063] Step S340: Send the contribution of all single-type instruction cycle consumption to the processor vector reduction unit. The vector reduction unit performs multi-level reduction in a binary tree structure, and merges the contribution of all instruction types in the same processing cycle into the total cycle consumption prediction.
[0064] The processor vector reduction unit is a hardware functional component that performs reduction operations between vector elements. Its binary tree structure is a hierarchical interconnection topology for the internal reduction data flow. Each stage consists of several parallel two-input reduction operators. The first stage pairs adjacent channels of the input vector and feeds them into an adder, producing a partial sum with half the input. The second stage pairs and reduces the input again, halving the input again. This process continues level by level until the final stage, outputting a single final reduction result. After reduction, the result is written to a general-purpose scalar register, which represents the sum of the cycle consumption contributions of all single-type instruction operations, i.e., the total cycle consumption prediction.
[0065] In one possible implementation, step S340 includes the following steps S341 to S345: Step S341: Pack all single-instruction cycle consumption contributions into a contribution vector aligned to the width of a vector register. If the number of contributions is less than the width of the vector register, fill the remaining channels in the vector register with a neutral value representing zero consumption, and load the filled contribution vector into the source vector register of the vector reduction unit.
[0066] Vector register width alignment refers to padding the contribution vector with the actual number of valid elements to match the number of elements the vector register hardware can accommodate. The number of neutral values to be filled is determined based on the number of contributions consumed in a single instruction cycle. Each contribution is sequentially written into the corresponding low-order channel of the contribution vector data structure, incrementing from channel zero. After writing all actual contributions, the remaining channels are cyclically written with integers 0 as neutral values representing zero consumption. Once all channels are filled, a vector loading instruction is executed, transferring the contribution vector to the source vector register of the vector reduction unit.
[0067] Step S342: Read the contribution vector from the source vector register through the vector reduction unit. In the first stage of the reduction pipeline, pair the contribution vectors according to the odd and even of the channel index. For each pair of channels, merge the contributions of the two channels into a partial sum through parallel reduction to obtain the first-stage partial sum vector with half the length.
[0068] The first stage of the reduction pipeline is the hardware operation logic closest to the source vector register within the vector reduction unit. The wiring logic connects the contributions of channel zero and channel one to the input of the first parallel integer adder, channels two and three to the second parallel integer adder, and so on. All adders complete the two-input addition operation within the same clock cycle, each producing a partial sum. These are rearranged according to the paired groups to form a first-stage partial sum vector with half the length, which is then passed to the next stage via the pipeline inter-stage forwarding register.
[0069] Step S343: The first-level partial sum vector is fed into the second stage of the reduction pipeline, and the merging is performed according to the odd and even pairing of the channel index to produce the second-level partial sum vector. This process is continued step by step until the final stage of the reduction pipeline outputs the final reduction result occupying a single channel. During the execution of the reduction pipeline, the partial sum vectors at each stage are kept in the vector register file and are not written back to the data buffer. Data transfer between stages is directly forwarded through the rename register to avoid introducing memory access latency.
[0070] The second stage of the reduction pipeline is similar to the first stage. The input is the partial sum vector from the first stage, which is then fed into an adder and merged according to the odd-even pairing rule, resulting in a second-stage partial sum vector whose length is halved again. This process continues stage by stage. For cases where the initial number of channels is not a power of 2, the reduction pipeline passes the single channel to the next stage via a direct path. The final stage feeds the last two partial sums into an adder and outputs the final reduced result occupying a single channel. The partial sum vectors at each stage always reside in the vector register file. Data transfer between stages is accomplished through renaming register mapping and forwarding data paths within the processor, without any write-back or load operations on the data cache.
[0071] Step S344: Read the final reduction result from the vector register file, convert it to a general-purpose integer register, and perform processor integer multiplication fusion with the global coupling adjustment amount corresponding to the current instruction combination obtained from the instruction type coupling adjustment table. Write the fusion result into the total cycle consumption prediction register.
[0072] The vector extraction instruction moves the final reduction result from the specified channel in the vector register file into a general-purpose integer register. The instruction type coupling adjustment table is a lookup table pre-built through offline performance profiling, using combination keys between different instruction types as indexes to store global coupling adjustments. The global coupling adjustment reflects the deviation of the total cycle cost from the sum of the cycle costs of each instruction individually when multiple different types of instructions are executed concurrently within the same logical frame. This deviation is caused by microarchitectural effects such as changes in cache hit rate, branch prediction interference, and pipeline stalls due to data dependencies. The final reduction result and the global coupling adjustment are then fed into an integer multiplier for multiplication and fusion. The fused result is written to the total cycle cost prediction register.
[0073] Step S345: After writing the fusion result to the total cycle consumption prediction register, perform a read-after-write data hazard check on the register. If the register address is found to match the address of an uncommitted write operation in the pipeline, the newly written fusion result is redirected to a new physical register through the register renaming mechanism to ensure that the value obtained when subsequent instructions read the total cycle consumption prediction is met.
[0074] Read-after-write hazard is a data-related problem in the processor instruction pipeline. It occurs when a previous instruction writes to an architecture register but hasn't committed it; subsequent instructions might read an undefined value if they directly access the register by its index. The processor microarchitecture's register renaming mechanism dynamically maps architecture registers to physical registers during the instruction decoding phase. This step proactively triggers a dependency check on the total cycle consumption prediction register: if the register address matches the address of an uncommitted write operation in the pipeline, the newly written fusion result is redirected to the new physical register via the renaming mapping table. Subsequent instructions reading this architecture register then retrieve the data from the latest physical register through the renaming mapping.
[0075] Step S350: Read the actual number of CPU cycles consumed by the previous completed logical frame recorded in the performance monitoring unit, and send it together with the total cycle consumption prediction corresponding to the previous completed logical frame into the processor differential comparator. The differential comparator outputs the deviation direction and amplitude signal, and latches the signal into the deviation correction latch.
[0076] The performance monitoring unit is a hardware unit integrated within the processor that monitors processor microarchitecture-level performance events. The actual CPU cycles consumed by the previous completed logical frame are the total number of CPU clock cycles consumed by the performance monitoring unit during the entire processing period of the previous logical frame that just finished executing. The processor differential comparator receives two input operands, calculates the absolute value of their difference, and outputs a deviation direction signal and a deviation amplitude code. The deviation correction latch is a set of processor-addressable registers that temporarily store the deviation direction and amplitude signals output by the comparator for use in the load estimate correction of step S360.
[0077] In one possible implementation, step S350 includes the following steps S351 to S356: Step S351: At the end of each logical frame execution, the CPU built-in performance monitoring unit is triggered to latch the number of CPU cycles counted during the duration of the logical frame into a model-specific register, and then a sampling completion signal is sent to the processor interrupt controller, which routes the sampling completion signal to the load monitoring dedicated interrupt handling routine.
[0078] Model-specific registers (MSRegs) are dedicated registers within the processor used for configuring and reading the performance monitoring unit (MMU). They are accessed through dedicated MMU read / write instructions. At the end of each logical frame execution, the main loop executes an instruction to write to the MMU control register, writing a latch command code to the MMU control register. The MMU then latches the currently accumulated CPU cycle count into the designated MMU. Subsequently, the MMU's internal interrupt generation logic sends a sampling completion interrupt request to the interrupt controller. The interrupt controller routes the signal to the interrupt vector corresponding to the load monitoring dedicated interrupt handling routine according to a preset interrupt vector routing table. The load monitoring dedicated interrupt handling routine is an interrupt service routine whose entry address is written into the interrupt descriptor table during the initialization phase, specifically for the interrupt vector number position used for load monitoring sampling completion notification.
[0079] Step S352: In the load monitoring dedicated interrupt handling routine, execute a bulk data transfer instruction from the model-specific register to the memory buffer, write the latched CPU cycle number along with the frame sequence number of the current logical frame to the tail of the circular history buffer, and atomically increment the write offset pointer of the buffer.
[0080] The circular history buffer is a fixed-size circular queue in server memory. Each record contains the frame number of the logical frame and the actual number of CPU cycles consumed by that frame. A write offset pointer indicates the slot index where the next new record should be written, incrementing modulo-based after each write. The interrupt handler executes a batch read instruction for the model-specific registers, reading the latch cycle count into a general-purpose register, and simultaneously reading the global frame number counter to obtain the frame number of the current logical frame. The memory address of the write location is calculated using the write offset pointer. The frame number and CPU cycle count are sequentially written to the corresponding fields. Then, an atomic increment operation is performed on the write offset pointer, followed by modulo-based increment to ensure wraparound.
[0081] Step S353: After generating a new total cycle consumption prediction, read the number of CPU cycles of the last written logical frame from the position indicated by the read offset pointer of the circular history buffer, use this number of CPU cycles as the actual number of CPU cycles consumed, and match it with the total cycle consumption prediction of the previous logical frame stored in the prediction history buffer.
[0082] The read offset pointer indicates the slot index of the next historical record to be read, and immediately follows the write offset pointer to point to the most recently written record. The prediction history buffer is a small memory area in the logical frame control block that temporarily stores the predicted total cycle consumption of the previous logical frame. The predicted total cycle consumption of the previous logical frame is read from the prediction history buffer and temporarily stored in the first general-purpose register. The CPU cycle count of the previously written logical frame is read from the corresponding slot in the circular historical record buffer using the read offset pointer as the actual CPU cycle consumption, and temporarily stored in the second general-purpose register, forming the pairing data for differential comparison.
[0083] Step S354: Write the actual CPU cycle consumption of the pair and the predicted total cycle consumption of the previous logic frame into the minuend latch and the subtrahend latch of the differential comparator, respectively, to enable the differential comparator to perform synchronous comparison. The output port of the differential comparator outputs the deviation direction signal and the deviation amplitude code.
[0084] The register value storing the actual CPU cycle consumption is written to the minuend latch of the differential comparator via the data bus, and the register value storing the predicted total cycle consumption of the previous logic frame is written to the subtrahend latch. After writing, an enable signal is written to the control port. The internal combinational logic of the differential comparator completes the subtraction and absolute value operations within the same clock cycle, and simultaneously presents the deviation direction signal and deviation magnitude code at the comparison result output port. The deviation direction signal is a single-bit signal; a high level indicates that the predicted value is lower than the actual consumption and a positive correction is needed, and a low level indicates that the predicted value is higher than the actual consumption and a negative correction is needed. The deviation magnitude code is a multi-bit binary code representing the magnitude of the absolute difference between the minuend and subtrahend.
[0085] Step S355: Temporarily store the deviation direction signal and deviation amplitude encoding in the deviation correction latch, and control the sign expansion logic of the deviation amplitude encoding according to the deviation direction signal. When the deviation direction signal indicates that the predicted amount is lower than the actual consumption, the deviation amplitude encoding is expanded to a positive correction amount, and vice versa.
[0086] The sign extension logic uses the deviation direction signal as the selection control to perform a signed numerical transformation on the deviation amplitude code. When the deviation direction signal is high, the deviation amplitude code is mapped to a positive correction value, meaning the deviation amplitude code is output as the positive part of a signed integer. When the deviation direction signal is low, the deviation amplitude code is inverted and incremented using its two's complement, mapping it to a negative correction value. The output after processing by the sign extension logic is the signed correction value, which is written back to the correction value field of the deviation correction latch.
[0087] Step S356: After the correction latch is completed, a lightweight write memory barrier instruction is sent to the processor to ensure that the contents of the deviation correction latch are visible to all processor cores before the subsequent load estimate fusion operation.
[0088] The lightweight write memory barrier instruction is a memory ordering constraint instruction provided by the processor instruction set. It ensures that the results of all store operations preceding this instruction are visible to all processor cores before any store or load operation following this instruction. In a multi-core environment, the server main loop may be scheduled to run on different cores. Before the merging operation in step S360, the correction amount in the bias correction latch must ensure that any processing core in the context or subsequent frame that reads the correction amount can see the latest written value. When executing the lightweight write memory barrier instruction, the processor emptys all incomplete write operations in the write merge buffer and the store buffer, and broadcasts the results to other processor cores within the cache coherency domain.
[0089] Step S360: Fuse the total cycle consumption prediction of the current logic frame with the correction amount represented by the deviation direction and amplitude signal in the deviation correction latch, and write the fusion result into the load prediction output register as the load prediction for the logic frame to be processed.
[0090] The total cycle consumption prediction for the current logic frame is the coupled-corrected cycle consumption prediction value calculated in steps S344 and S345 and stored in the total cycle consumption prediction register. The total cycle consumption prediction is loaded into the first source operand register, and the signed correction value in the deviation correction latch is loaded into the second source operand register. A signed integer addition instruction is executed in the arithmetic logic unit, and the addition result represents the cycle consumption prediction value after historical deviation correction. The addition result is written to the load estimate output register via a data transfer instruction; the value stored in this register is the load estimate for the logic frame to be processed.
[0091] Step S400: Based on the comparison between the load estimate and the single-frame logic processing budget, perform instruction classification admission processing on the instruction packets in the current processing cycle. Move instruction packets belonging to the non-critical instruction category into the non-critical instruction temporary storage queue, submit instruction packets belonging to the critical instruction category to the logic frame execution process, and when the load estimate is detected to fall back to the preset safety threshold, batch retrieve the instruction packets in the non-critical instruction temporary storage queue and resume processing.
[0092] The single-frame logic processing budget is the upper limit of CPU cycle consumption set during the system design phase for a single logic frame, calculated based on the server's target frame rate and processor clock speed. Critical instruction categories refer to instruction types that play a core supporting role in the correctness of game logic and the smoothness of player experience, while non-critical instruction categories refer to instruction types whose execution can be moderately delayed without compromising the basic correctness of game logic. The non-critical instruction temporary storage queue is a first-in, first-out queue data structure. The preset safety threshold is a safety level below the single-frame logic processing budget. If the estimated load is less than or equal to the single-frame logic processing budget, all instruction packets are submitted to the logic frame execution flow. If the estimated load exceeds the single-frame logic processing budget, instruction hierarchical admission processing is initiated: the instruction packet temporary storage area is traversed, the instruction type tag of each instruction packet is extracted, and an existence check is performed against the critical instruction classification table. Instructions belonging to the critical instruction category are routed to the logic frame submission buffer, while those belonging to the non-critical instruction category are routed to the non-critical instruction bypass buffer and moved into the non-critical instruction temporary storage queue. When the estimated load value no longer exceeds the preset safety threshold in several consecutive logical frames, the first batch of temporary records are popped from the non-critical instruction temporary storage queue, restored to the original instruction packet, and merged into the instruction packet temporary storage area of the next logical frame to be processed.
[0093] In one possible implementation, step S400 includes the following steps S410 to S460: Step S410: Write the load estimate and the single-frame logic processing budget into the source operand 1 register and source operand 2 register of the processor comparison unit, respectively, enable the comparison unit to perform unsigned integer comparison operation, read the condition code flag bit output by the comparison unit, and determine whether the load estimate exceeds the single-frame logic processing budget based on the condition code flag bit.
[0094] The processor's comparison unit is a sub-functional unit within the arithmetic logic unit that performs comparison operations. It subtracts the value of source operand two register from the value of source operand one register, discarding the result and setting only the condition code flag based on the subtraction result. Two data transfer instructions are executed to load the estimated load value into source operand one register and the single-frame logic processing budget into source operand two register, issuing unsigned integer comparison instructions. After performing the subtraction operation, the comparison unit sets the condition code flag: if source operand one is greater than source operand two, the carry flag is set, indicating that the estimated load value exceeds the budget; otherwise, the carry flag is cleared. A conditional branch instruction is executed to read the carry flag and determine the execution path.
[0095] Step S420: When it is determined that the load estimate exceeds the single-frame logic processing budget, traverse each instruction packet in the instruction packet temporary storage area of the current processing cycle, extract the instruction type label at the fixed offset of the instruction packet header, perform a label existence check on the instruction type label and the set of key instruction labels in the key instruction classification table, and use the label existence check result to drive the selection signal of the instruction packet routing multiplexer.
[0096] The current processing cycle instruction packet buffer is a temporary buffer that stores parsed instruction packets, maintaining the order in which they were received. The key instruction tag set in the key instruction classification table is implemented using a hash set that supports fast existence lookup. Each instruction packet is retrieved sequentially starting from the beginning address of the instruction packet buffer, and the value of the instruction type tag field is extracted from a fixed offset in the instruction packet header according to the binary protocol format. Using this tag value as the lookup key, the existence check interface of the key instruction tag set is called, quickly determining whether the packet exists in the hash set based on the hash value and bucket index. The returned boolean value is written to the selection signal input of the instruction packet routing multiplexer.
[0097] Step S430: The instruction packet routing multiplexer routes instruction packets that do not exist in the critical instruction tag set to the non-critical instruction bypass buffer according to the selection signal, and routes instruction packets that exist in the critical instruction tag set to the logical frame submission buffer.
[0098] The instruction packet routing multiplexer has one input and two outputs. The input is connected to the current instruction packet data bus in the instruction packet buffer, the first output is connected to a non-critical instruction bypass buffer, and the second output is connected to a logic frame commit buffer. When the selection signal indicates that the instruction packet does not exist in the critical instruction tag set, the multiplexer connects the input data path to the first output, and the instruction packet is sent to the non-critical instruction bypass buffer. When the selection signal indicates that the instruction packet exists, the multiplexer connects the input data path to the second output, and the instruction packet is sent to the logic frame commit buffer. After all instruction packets have been traversed and routed, the critical instruction packets in the logic frame commit buffer are directly committed to the logic frame execution flow.
[0099] Step S440: In the non-critical instruction bypass buffer, append a monotonically increasing sequence number generated by an atomic increment counter and the current system timestamp to each received instruction packet to obtain a non-critical instruction temporary storage record, and write the non-critical instruction temporary storage record into the non-critical instruction temporary storage queue through a lock-free tail pointer update operation.
[0100] The atomic increment counter implements atomic increment operations under multi-threaded concurrency using atomic increment instructions with a lock prefix. Each operation returns the count value before increment as a monotonically increasing sequence number, which is globally unique and strictly monotonically increasing throughout the server's runtime. The system timestamp is obtained by reading the timestamp counter and converting it. The non-critical instruction temporary storage record is a complete temporary storage data structure composed of metadata fields such as the monotonically increasing sequence number and the system timestamp appended to the beginning and end of the original instruction packet. The lock-free tail pointer update operation uses atomic compare-swap instructions to update the tail pointer of the non-critical instruction temporary storage queue in a lock-free manner, ensuring the correctness of the enqueue operation without a mutex lock.
[0101] In one possible implementation, step S440 includes the following steps S441 to S446: Step S441: Define the memory layout of the non-critical instruction temporary storage record: The record header stores a monotonically increasing sequence number, followed by the system timestamp, then the original instruction packet length field, and finally the payload byte sequence of the original instruction packet. The alignment granularity of the entire record is the main memory access granularity.
[0102] In a 64-bit processor architecture, main memory access granularity is 8 bytes. A monotonically increasing sequence number occupies the first 8 bytes of the record, the system timestamp occupies the following 8 bytes, and the raw instruction packet length field occupies 4 bytes, totaling 20 bytes forming a fixed-length metadata header. The payload byte sequence of the raw instruction packet is stored immediately after the metadata header, and its length is indicated by the raw instruction packet length field. The total byte length of the entire record is aligned upwards to an integer multiple of 8 bytes; any shortfall is padded with zero-valued padding bytes at the end of the payload sequence.
[0103] Step S442: When the non-critical instruction bypass buffer receives an instruction packet, retrieve the current count value from the atomic increment counter as the monotonically increasing sequence number, and then increment the atomic increment counter. At the same time, read the system timestamp counter to obtain the system timestamp, and write the monotonically increasing sequence number and the system timestamp into the pre-allocated non-critical instruction temporary storage memory area.
[0104] The atomic increment counter is located and initialized to 1 during server initialization. This is accomplished within a single indivisible bus transaction via an atomic increment instruction with a lock prefix: after the processor core acquires exclusive ownership of the cache line corresponding to that address, it reads the current counter value as a monotonically increasing sequence number and writes it to the target general-purpose register, while simultaneously incrementing the counter value and writing it back to memory. A timestamp counter read instruction is executed to obtain the current count value and convert it to a system timestamp proportional to a fixed clock frequency. In the non-critical instruction temporary storage memory area pre-allocated from the memory pool for this instruction packet, the monotonically increasing sequence number is written to the first 8 bytes according to the memory layout defined in step S441, and the system timestamp is written to the following 8 bytes.
[0105] Step S443: After writing the monotonically increasing sequence number and system timestamp, copy the payload byte sequence of the original instruction packet to the payload area of the non-critical instruction temporary storage memory area in double-byte alignment. During the copying process, the processor is prohibited from speculative read operations on this area. A prefetch stop instruction is inserted to prevent the prefetcher from loading payload data that has not been fully written in advance.
[0106] The payload byte sequence of the original instruction packet is the sequence of bytes carrying the specific operation parameters after removing the header protocol control fields. Copying is performed using a loop structure. Each time, a load instruction fetches two bytes from the source address and writes them to the destination address as a store instruction. Both the source and destination addresses are incremented by 2, and the remaining length is decremented by 2, until all payload bytes have been copied. A prefetch stop instruction is inserted before the copy loop begins, informing the processor hardware prefetcher to prohibit speculative prefetch requests for this address range, preventing the prefetcher from prematurely loading incomplete intermediate state data. Optionally, a prefetch resume instruction is inserted after the copy loop ends to restore the prefetch behavior.
[0107] Step S444: After the payload copy is completed, immediately perform a full write barrier operation on the start and end addresses of the non-critical instruction temporary storage record memory area, flush the write merge buffer, and submit all fields of the record to the global visibility point of the storage subsystem.
[0108] A write merge buffer is a hardware buffer structure within the processor that temporarily stores write operation data that has not yet been committed to main memory or shared cache. A full write barrier operation forcibly empties all data in the write merge buffer, committing the data to be written to a globally visible point within the cache coherency domain. A full memory barrier instruction or a cache line flush and write-back instruction for that address range is issued. The processor waits until all incomplete write operations for that address range in the memory buffer have completed the coherency protocol commit process and returned an acknowledgment signal to the core before continuing to execute subsequent instructions.
[0109] Step S445: Read the current tail pointer of the non-critical instruction temporary storage queue, and perform an atomic comparison and swap between the value of the successor pointer field pointed to by the tail pointer and the current value of the tail pointer. If the swap is successful, the new record has been linked into the queue. If the swap fails, reread the new tail pointer and repeat the comparison and swap until the linking is successful.
[0110] The non-critical instruction temporary storage queue adopts a lock-free queue based on a singly linked list. Each node is a temporary record for a non-critical instruction, and the end of the record contains a successor pointer field pointing to the next record in the queue. The tail pointer is an atomic pointer variable pointing to the last node of the queue. An atomic load operation reads the current tail pointer value to locate the tail node; the current value of the tail node's successor pointer field is a null pointer. An atomic comparison and swap instruction is executed, using the memory address of the tail node's successor pointer field as the target address, the null pointer as the expected value, and the starting address of the new record as the new value. If the swap is successful, the successor pointer has been atomically updated to point to the new record, and the new record is successfully linked into the queue. If the swap fails, it means that other concurrent operations have preemptively modified the successor pointer; the returned current actual value is used as the new tail pointer, and the comparison and swap are retried until successful.
[0111] Step S446: After the link is successfully established, update the tail pointer of the non-critical instruction temporary storage queue to point to the tail address of the new record, and atomically increment the queue length counter. When the value of the queue length counter exceeds the preset capacity limit, trigger the queue congestion control signal to notify the queue head recycling logic to start the process of discarding non-critical instruction temporary storage records and reclaiming memory.
[0112] Using the old tail pointer value loaded atomically as the expected value and the starting address of the new record as the new value, an atomic comparison and swap operation is performed on the tail pointer variable of the non-critical instruction temporary storage queue to update the tail pointer. If this fails, the tail pointer is reread and the process is retried. After the tail pointer is updated, an atomic increment operation is performed on the queue length counter. This counter is a global atomic integer variable that records the number of temporary records in the queue in real time. The incremented count value is compared with the preset capacity limit. When the limit is exceeded, a queue congestion control signal is triggered. The head-of-queue reclamation logic discards the earliest record that entered the queue and reclaims memory, starting from the head of the queue and in ascending order of timestamp, until the queue length falls below the safety line.
[0113] Step S450: After completing the instruction submission of the current logic frame, continuously monitor the load estimate of subsequent logic frames. When it is detected that the load estimate no longer exceeds the preset safety threshold in several consecutive logic frames, start from the head of the non-critical instruction temporary storage queue and pop the non-critical instruction temporary storage records in batches according to the monotonically increasing sequence number.
[0114] In the load estimation processing stage of each subsequent logical frame, the load estimate generated in step S360 is continuously acquired and compared with a preset safety threshold. The preset safety threshold is the value of the single-frame logical processing budget multiplied by a safety factor. When the consecutive comparison results are all load estimates less than or equal to the preset safety threshold, and the number of consecutive logical frames meeting this condition reaches a preset fallback length constant, it is determined that the server load has stably fallen back to a safe level. Starting from the head of the non-critical instruction temporary storage queue, each record is accessed sequentially along the linked list by traversing the successor pointer field, and records are retrieved in ascending order of monotonically increasing sequence number.
[0115] In one possible implementation, step S450 includes the following steps S451 to S456: Step S451: After generating the load estimate in each logical frame, the load estimate and the preset safety threshold are sent to the comparator to obtain the comparison result. If the comparison result indicates that the threshold is not exceeded, a dedicated continuous fallback length counter is driven to increment. If the comparison result indicates that the threshold is exceeded, the continuous fallback length counter is cleared to zero.
[0116] The dedicated continuous fallback length counter is an integer variable allocated in the logical frame control block, tracking the number of logical frames in which the load estimate does not exceed a preset safety threshold consecutively. After generating the load estimate for each frame, a comparison instruction is executed to perform an unsigned integer comparison. If the load estimate does not exceed the preset safety threshold, an increment instruction is executed on the continuous fallback length counter; if it exceeds the threshold, an immediate value of 0 is written to the continuous fallback length counter to reset it. Any single frame exceeding the threshold will reset the fallback determination process to its initial state.
[0117] Step S452: When the count value of the continuous fall-off length counter is equal to the preset fall-off length constant, set the load fall-off status flag, generate a load fall-off confirmation signal, and immediately reset the continuous fall-off length counter after setting.
[0118] The preset fallback length constant is a positive integer configured by the system. The current value of the continuous fallback length counter is compared with the preset fallback length constant using a comparison instruction. If they are equal, the load fallback status flag is set from logic 0 to logic 1 using a bit setting instruction, generating a load fallback confirmation signal. Then, a value of 0 is written to the continuous fallback length counter to reset it.
[0119] Step S453: During the period when the load fall-off status flag is set, continuously monitor the local jitter of the load estimate, and send the difference between the load estimates of adjacent logic frames to the jitter amplitude detector. If the amplitude output by the jitter amplitude detector exceeds the preset jitter tolerance, clear the load fall-off status flag and restart the fall-off determination.
[0120] Local jitter in load forecast refers to the instantaneous fluctuation in load forecast values between adjacent logical frames. The absolute value of the difference between the current frame's load forecast value and the previous frame's load forecast value is calculated using a subtractor as the jitter amplitude. This jitter amplitude is compared to a preset jitter tolerance using a comparator. If the jitter amplitude exceeds the preset tolerance, the load fallback status flag is cleared and reset to logic 0. Simultaneously, the continuous fallback length counter is reset to zero, delaying the batch pop-up operation until the next stable fallback cycle. If the jitter amplitude does not exceed the tolerance, the load fallback status flag remains set.
[0121] Step S454: With the load fallback status flag set, start a delay window based on a timestamp counter. After the delay window expires, perform a batch pop operation on the non-critical instruction temporary storage queue: starting from the record pointed to by the head pointer, traverse the records sequentially and check the continuity of the monotonically increasing sequence number of the records.
[0122] The timestamp-counter-based delay window utilizes the processor's timestamp counter to implement programmable delay timing. After the load fallback status flag is set and jitter detection passes, the current timestamp counter value is read, added to a preset delay window width constant to obtain the expiration time count, and stored. At the beginning of each logical frame, the current timestamp counter is read and compared with the expiration time; the delay window expires when the current count is greater than or equal to the expiration time. Starting from the head pointer of the non-critical instruction temporary storage queue, records are traversed, and the monotonically increasing sequence number of each record is compared with the monotonically increasing sequence number of the previously popped record plus 1 to check sequence number continuity.
[0123] Step S455: During the traversal, if the monotonically increasing sequence number of the record is found to be discontinuous, the popping is paused, the traversed record slices are used to form a batch popping set, the records in the batch popping set are deserialized, the monotonically increasing sequence number and system timestamp are stripped, the original instruction packet is restored and spliced into the instruction sequence.
[0124] The traversed record slice is a continuous subsequence of records that has been successfully traversed and passed the continuity check before the discontinuity of the monotonically increasing sequence number is discovered. Deserialization is performed on each record in the batch pop set: according to the memory layout defined in step S441, the value of the original instruction packet length field is located and read from the record header. Based on this length value, an equal-length original instruction packet payload byte sequence is copied from the payload area, written to the newly allocated instruction packet memory area, and a complete original instruction packet conforming to the standard protocol format is reconstructed. The monotonically increasing sequence number and system timestamp are read during this process for sequence continuity checking and then discarded. The recovered original instruction packets are sequentially concatenated into the contiguous memory storage area of the instruction sequence in traversal order.
[0125] Step S456: After the instruction sequence is assembled, the load fallback status flag is deactivated, the delay window is reset to its initial value, and a ready signal for pending instructions is sent to the instruction scheduler, indicating that the next logical frame processing flow includes instruction packets recovered from the non-critical instruction temporary queue.
[0126] The instruction scheduler is a scheduling module within the server's main loop that manages the set of instruction packets to be processed in each logical frame. It performs a load fallback status flag clearing operation, resetting it from logic 1 to logic 0, and resets the delay window expiration time counter register to its initial value, indicating that the delay window is not enabled. An instruction ready signal is written to the instruction scheduler. After detecting this signal during the next logical frame instruction packet buffer preparation phase, the instruction scheduler inserts the restored instruction sequence assembled in step S455 into the instruction packet buffer of the next logical frame, allowing the restored non-critical instruction packets to enter the logical frame execution flow together with the normally received player operation instruction packets.
[0127] Step S460: For the popped-up non-critical instruction temporary record, remove the attached monotonically increasing sequence number and system timestamp, recover the original instruction packet, merge the recovered instruction packet into the header of the instruction packet temporary storage area of the next logic frame to be processed, and keep the original arrival order of each instruction packet unchanged.
[0128] According to the memory layout defined in step S441, skip the monotonically increasing sequence number field and system timestamp field in the record header, locate the original instruction packet length field and payload byte sequence, and reassemble the payload byte sequence with the protocol control field in the instruction packet header into a standard format original instruction packet. Multiple recovered original instruction packets are merged into the instruction packet buffer header of the next pending logical frame, ensuring that deferred non-critical instruction packets are processed before newly received player operation instruction packets in the current frame. The recovered instruction packets are arranged in ascending order using monotonically increasing sequence numbers to strictly maintain their original arrival order.
[0129] Step S500: During the period when the server is in an idle load state, standard instruction sequences are actively injected into the logical frame execution process, the actual execution time of the standard instruction sequences is collected, the actual execution time is compared with the baseline overhead weight of the corresponding instruction type label in the instruction-overhead mapping table, and the baseline overhead weight is updated online based on the result of the deviation comparison.
[0130] Idle load state refers to a server operation state where the density of player operation command flow is significantly lower than normal, the CPU utilization of the server's main loop is at a low level, and there are sufficient computing resources to execute background tasks. A standard instruction sequence is a pre-compiled set of standard instruction packages for each instruction type, containing the most representative typical operation parameters for that type. Actual execution time is the number of CPU cycles consumed from the function entry to the return after the standard instruction package is fully executed by the instruction processing function. It is precisely measured by inserting serialized timestamps at the function entry and exit points. Deviation comparison quantitatively compares the actual execution time with the current baseline overhead weights to analyze the direction and magnitude of the deviation. Online self-calibration update automatically and incrementally corrects the baseline overhead weights in the mapping table during server process operation without manual intervention, gradually bringing them closer to the actual processing overhead of each instruction type under the current hardware environment and software version.
[0131] In one possible implementation, step S500 includes the following steps S510 to S560: Step S510: Periodically read the processor's built-in power management status register, extract the processor's average occupancy status bit segment from the power management status register, and if the occupancy status indicated by the bit segment is continuously within the idle judgment range within a preset length time window, then confirm that the server has entered the idle load state by setting the idle status flag trigger.
[0132] The processor's built-in power management status register is a model-specific register that reports the current power management status. The value of the processor's average occupancy status bit segment reflects the proportion of time the processor cores were in a non-sleep state within a past sampling window. The register value is obtained by executing a model-specific register read instruction, and the value of the processor's average occupancy status bit segment is extracted using masking and shift operations. The extracted value is compared with the upper limit of the idle judgment range. If it is less than or equal to the upper limit, the continuous idle time accumulator is incremented; otherwise, the continuous idle time accumulator is cleared. The current value of the continuous idle time accumulator is compared with a preset time window. When it is greater than or equal to the time window, the idle status flag trigger is set from logic 0 to logic 1, confirming that the server has entered an idle load state.
[0133] Step S520: After the idle state flag trigger is set, the standard instruction skeletons of each instruction type to be calibrated are sequentially read from the standard instruction template read-only storage area. The reserved operation number segments of each standard instruction skeleton are filled with dummy data in the test mode. After filling, a standard instruction package carrying instruction type tags is generated, and these standard instruction packages are linked into a chain injection sequence.
[0134] The standard instruction template read-only memory area is a contiguous memory region generated during compilation and linking within the read-only data segment of the server executable file. It stores the standard instruction skeletons for all calibrable instruction types. A standard instruction skeleton is an instruction package template containing instruction type labels and a fixed structure, but with the operand field in an unfilled reserved state. Dummy metadata in test mode is data used in calibration scenarios that is representative but has no actual game semantic impact. The process iterates through the preset list of instruction types to be calibrated, finds the corresponding standard instruction skeleton in the read-only memory area for each label, creates a modifiable copy in the working buffer, locates the reserved operand field in the copy, and fills in the corresponding dummy metadata according to the protocol format. After filling, confirms the instruction type label field is correctly set, and appends a node pointing to the standard instruction package to the end of the chained injection sequence. The chained injection sequence is completed after all calibrated types have been processed.
[0135] Step S530: By sending an injection request to the instruction injection side channel of the logical frame execution flow, the injection request carries the address pointer and length of the standard instruction packet. When the logical frame execution flow completes the processing of the current player's instruction packet and the instruction pipeline is idle, it retrieves the standard instruction packet from the side channel and schedules its instruction processing function to execute.
[0136] The instruction injection side channel is a shared memory message slot or a lock-free single-producer, single-consumer queue for transmitting background injection instructions between the main loop and the logic frame execution flow. The injection request contains the address pointer and length information of the standard instruction packet. After the logic frame execution flow has successfully processed all player operation instructions for the current frame, it checks if there are any unprocessed injection requests in the instruction injection side channel. If so, and the instruction pipeline is idle, the injection request is retrieved from the side channel, the complete content of the standard instruction packet is read based on the address pointer and length, the entry address of the corresponding instruction processing function is found based on the instruction type label, and the instruction processing function is executed via function call instruction scheduling.
[0137] Step S540: Insert serialized instructions to read the timestamp counter at the first instruction address and the last instruction address of the instruction processing function of the standard instruction packet, respectively, and store the read timestamp count value in the thread-local storage area associated with the injection sequence number of the standard instruction packet. After the instruction processing function returns, calculate the interval between the timestamp at the last instruction address and the timestamp at the first instruction address as the execution time of a single execution.
[0138] The serialization instruction that reads the timestamp counter forcefully flushes all incomplete instructions from the processor instruction pipeline during execution. It waits until all memory operations are complete and globally visible before reading the timestamp counter value, ensuring that the timestamp accurately marks the precise moment of the instruction within the program execution flow. The standard instruction packet injection sequence number is an incrementing integer assigned to each standard instruction packet when constructing the chained injection sequence. Thread-local storage areas are memory regions dedicated to each worker thread, accessed through the thread-local storage base address register.
[0139] In one possible implementation, step S540 includes the following steps S541 to S546: Step S541: When compiling the target code of the instruction processing function corresponding to the standard instruction package, insert a serialization instruction to read the timestamp counter before the basic block of the function entry. This serialization instruction prevents the instruction scheduler from reordering it with the previous instructions and drains all unfinished memory operations in the processor pipeline during execution.
[0140] The basic block of a function entry point is the first continuous sequence of instructions without branches executed when the function is called. During the compilation phase, a serialized instruction to read the timestamp counter is inserted before the first instruction of the basic block of the function entry point, either through inline assembly or a compiler-built-in function. This instruction is marked as having full scheduling barrier properties during the compiler instruction scheduling phase, prohibiting the instruction scheduler from reordering any instruction preceding this instruction to after it, and also prohibiting the reordering of any instruction following this instruction to before it. When the processor executes this instruction, it first waits for all earlier issued instructions to complete completely and commit their architectural state, then emptys all incomplete memory operations from the memory buffer and write merge buffer, and after confirming that all memory side effects are globally visible, it reads the current count value from the timestamp counter and writes it to the destination register.
[0141] Step S542: Immediately after the serialization instruction, insert a storage instruction to write the read timestamp count value to a storage slot with the thread-local storage base address register as the base address and the standard instruction packet injection sequence number as the index offset. Then, insert a write barrier instruction after this storage instruction to force the storage result to be visible to other threads.
[0142] The absolute memory address of the target memory slot is calculated by multiplying the standard instruction packet injection sequence number by the size of each timestamp storage slot and adding the base address in the thread-local storage base address register. A store instruction writes the timestamp count value read by the serialization instruction to this address. A write barrier instruction is inserted after this store instruction, forcibly flushing the current processor core's memory buffer during execution. This ensures that the newly written timestamp count value is committed to the cache coherency field, allowing the statistics thread or other monitoring threads to observe the timestamp value.
[0143] Step S543: At the end of the last basic block before the return instruction of the instruction processing function, insert the serialization instruction to read the timestamp counter again, read the timestamp count value before the return, and store it in another storage slot in the thread-local storage area corresponding to the injection sequence number.
[0144] The last basic block before the return instruction is the sequence of instructions that return control to the caller upon the function's final execution. At the end of this basic block, before the return instruction, the compiler inserts a serialization instruction to read the timestamp counter, retrieving the timestamp count value indicating the function is about to complete all logical calculations and is preparing to return. Following this instruction, a store instruction is inserted, writing the timestamp count value to the second slot in the thread-local storage area corresponding to the current injection sequence number, but different from the slot in step S542. This slot offset is equal to the slot offset in step S542 plus the fixed slot interval offset. After the store instruction, a write barrier instruction is inserted to ensure that the timestamp written at the return moment is visible to other threads.
[0145] Step S544: After the instruction processing function returns, the injection management routine loads the function entry timestamp count and the function return timestamp count from two storage slots in the thread local storage area, respectively, and calculates the difference between the two through the processor subtraction unit, and writes the difference into the single execution time record.
[0146] The injection management routine is the management code segment in the main loop responsible for injecting standard instruction packages and reclaiming measurement data. It executes a load instruction from the thread-local storage area, indexed by the injection sequence number, to read the function entry timestamp count from the entry timestamp slot and store it in the first general-purpose register. It also reads the function return timestamp count from the return timestamp slot and stores it in the second general-purpose register. An integer subtraction instruction is issued, using the return timestamp count in the second general-purpose register as the minuend and the entry timestamp count in the first general-purpose register as the subtrahend. The subtraction unit calculates the difference between the two and writes it to the third general-purpose register. This difference represents the number of processor timestamp count cycles elapsed from function entry to return, and is recorded as the single execution time in a single execution time record associated with the instruction type label and injection sequence number.
[0147] Step S545: Before writing the single execution time record, check whether the processor core identifiers corresponding to the values in the two storage slots are consistent. If the core identifiers are inconsistent, it indicates that a process migration has occurred during execution. In this case, discard the single execution time record and reschedule the standard instruction package for injection execution.
[0148] The processor core identifier is a unique number for each processor core in the system, obtained by reading the processor core identifier register. During the timestamp storage operations in steps S541 and S543, the processor core identifier of the currently executing thread is simultaneously written to a reserved field near the storage slot. The core identifier values for the entry and return times are loaded from the core identifier fields of the two storage slots and sent to a comparator for equality comparison. If the two core identifier values are different, it indicates that the instruction processing function was migrated to another processor core by the operating system thread scheduler during execution. The entry and return timestamps are read from the timestamp counters of different cores, and the difference may not accurately reflect the actual execution time due to possible incomplete synchronization between the timestamp counters. In this case, the current time record is discarded, the standard instruction packet is placed back into the unexecuted queue of the chained injection sequence, and rescheduled for measurement during a subsequent idle period.
[0149] Step S546: If the core identifiers are consistent, the single execution time record, together with the instruction type label and the current processor core's operating frequency scaling factor, is packaged and sent to the statistics thread through an unlocked circular buffer. The statistics thread then compensates for the operating frequency scaling factor before returning it to the time consumption sample buffer pool.
[0150] The operating frequency scaling factor is an instantaneous operating parameter under the processor's dynamic frequency adjustment technology. Its value is the ratio of the processor core's current operating clock frequency to the nominal reference frequency, or a fixed-point number encoding, obtained by reading the model-specific registers of the frequency monitoring interface. The lock-free circular buffer is a shared memory area between the statistics thread and the main loop used for low-latency, lock-free transfer of calibration sample data. The statistics thread is an independently running background thread specifically responsible for the statistical processing of calibration samples and updating the reference overhead weights. The single execution time record, instruction type label, and the current processor core operating frequency scaling factor read during execution are packaged into a calibration sample data packet and written to the producer slot of the lock-free circular buffer. After retrieving the data packet from the consumer slot, the statistics thread uses the operating frequency scaling factor to perform frequency compensation on the single execution time: multiplying the measured number of cycles by the operating frequency scaling factor to calculate the equivalent number of cycles at the reference frequency. After compensation processing, the data is stored in the time-consuming sample buffer pool corresponding to the instruction type label.
[0151] Step S550: The execution times of multiple single executions obtained by injecting and executing standard instruction packages with the same instruction type label multiple times are collected into the time consumption sample buffer pool corresponding to the instruction type label. When the number of samples in the buffer pool reaches the preset number of aged samples, the earliest sample entering the pool is discarded and the new sample is pushed into the end of the pool to keep the number of samples in the buffer pool within the preset number of aged samples.
[0152] The time-consuming sample buffer pool is a fixed-capacity sample queue independently allocated to each instruction type label to be calibrated. It is organized in memory as a circular array, with each element representing the single execution time value after frequency compensation processing in step S546. The preset aging sample count is the maximum capacity of the buffer pool, representing the upper limit of the latest sample count for actual execution time used in statistical calculations. The buffer pool maintains a sample count counter and front and rear indices; new samples are pushed into the rear of the queue. When the sample count reaches the preset aging sample count, the front index moves forward one position, the earliest sample added to the pool is logically discarded, and new samples are still pushed into the rear of the queue, ensuring the sample count in the pool remains at the preset aging sample count. This sliding window-style sample management mechanism ensures that the time-consuming sample data used for weight updates always reflects the recent operational characteristics of the server.
[0153] Step S560: After each new sample is pushed in, all samples in the time-consuming sample buffer pool are traversed, and the samples are sent to the comparison and sorting network to determine the central position of the sample distribution. The sample at the central position is taken as the actual execution time of the instruction type label, and the actual execution time is submitted to the baseline overhead weight update process.
[0154] The comparison sorting network is an algorithm that uses a predefined, fixed sequence of comparison and swap operations to find the median. The median is the value at the exact middle of the sequence after all samples in the buffer are sorted in ascending order. Using the median effectively eliminates the impact of extreme outlier values caused by external disturbances such as occasional system interruptions or cache misses on the statistical results. After determining the actual execution time, the statistics thread submits it to the baseline cost and weight update process.
[0155] In one possible implementation, step S560 submits the actual execution time to the baseline cost weight update process, including the following steps S561 to S566: Step S561: The actual execution time and the current baseline overhead weight corresponding to the instruction type label read from the instruction-overhead mapping table are latched to the first and second inputs of the comparator, respectively. The comparator generates a difference indication signal, which includes the deviation direction of the actual execution time relative to the current baseline overhead weight and the absolute difference magnitude.
[0156] The median execution time, determined by sorting, is retrieved from the time-consuming sample buffer and written to the first general-purpose register. Using the instruction type label as an index, the instruction-overhead mapping table lookup process is invoked to read the currently stored baseline overhead weight and write it to the second general-purpose register. The values of both registers are latched to the first and second inputs of the comparator, respectively, enabling the comparator to perform synchronous comparison. The internal subtractor calculates the difference between the first and second inputs: if the difference is positive, the deviation direction is positive, indicating that the actual execution time is greater than the current baseline overhead weight; if the difference is negative, the deviation direction is negative, indicating that the actual execution time is less than the current baseline overhead weight. The absolute value of the difference is the absolute difference magnitude.
[0157] Step S562: Input the absolute difference magnitude to the step size mapping logic circuit. The step size mapping logic circuit divides the absolute difference magnitude into multiple continuous intervals. Each interval corresponds to a pre-configured adjustment step size. Output the adjustment step size corresponding to the interval where the current absolute difference magnitude is located.
[0158] In software implementation, the step-size mapping logic circuit is represented by a static mapping array or a conditional branch structure. The relative difference ratio is obtained by dividing the absolute difference magnitude by the current baseline overhead weight. The absolute difference magnitude is then divided into several continuous intervals according to this ratio, with each interval's boundary value representing a different ratio. Each interval corresponds to a preset adjustment step size. Intervals with larger ratios correspond to larger adjustment step sizes, enabling a variable step-size strategy for fine-tuning small deviations and rapid tracking of large deviations. Based on the interval where the current absolute difference magnitude falls, the corresponding adjustment step size is output from the mapping table.
[0159] Step S563: Based on the deviation direction, assign a direction attribute to the adjustment step size. When the deviation direction indicates that the actual execution time is greater than the current baseline cost weight, assign a positive adjustment attribute; otherwise, assign a negative adjustment attribute to obtain a signed adjustment amount.
[0160] If the deviation direction in step S561 is positive, the adjustment step size is assigned a positive adjustment attribute, maintaining a positive value. If the deviation direction is negative, the adjustment step size is assigned a negative adjustment attribute, converting it to a corresponding negative value through the inversion and addition operation of binary two's complement. After the sign assignment, the adjustment step size becomes a signed adjustment amount, containing the amplitude and direction information updated in this step.
[0161] Step S564: Combine the signed adjustment amount with the current reference overhead weight in the adder to obtain the unprotected candidate reference overhead weight, and transmit the candidate reference overhead weight to the threshold protection unit.
[0162] The signed adjustment is loaded into the first input register of the adder, and the current reference overhead weights are loaded into the second input register of the adder. A signed integer addition operation is then performed. The sum of the adder outputs is the candidate reference overhead weight, reflecting the theoretically new weights obtained after directly incorporating the current calibration measurement results. The candidate reference overhead weights are then transmitted to the threshold protection unit for safety protection.
[0163] Step S565: The threshold protection unit detects whether the candidate reference cost weight exceeds the preset effective range of the weight. If the candidate reference cost weight is lower than the lower boundary of the preset effective range of the weight, the lower boundary value is replaced with the candidate reference cost weight. If it is higher than the upper boundary, the upper boundary value is replaced with the candidate reference cost weight. If it is within the range, the original value is kept and the protected reference cost weight is output.
[0164] The preset weight effective range is a reasonable closed interval set for each instruction type. The lower and upper boundaries are determined by multiplying the cycle consumption value (after frequency normalization) measured for the instruction type in the most concise and most complex processing paths by a safety extension factor. The threshold protection unit contains two comparators: one determines whether the candidate reference overhead weight is less than the lower boundary value, and the other determines whether it is greater than the upper boundary value. The multiplexer selects the output based on the comparison result: if it is less than the lower boundary, it outputs the lower boundary value; if it is greater than the upper boundary, it outputs the upper boundary value; if it is within the range, it outputs the original value of the candidate reference overhead weight. The multiplexer output value is the protected reference overhead weight.
[0165] Step S566: Update the protected baseline overhead weight to the entry corresponding to the instruction type label in the instruction-overhead mapping table through an atomic write operation, and execute the cache line refresh instruction to broadcast the updated baseline overhead weight to the cache coherence domain of all processor cores.
[0166] Atomic write operations are performed using a natural alignment scalar store instruction in conjunction with memory barriers, ensuring that the written data is fully visible in global memory order at once. The corresponding entry in the instruction-overhead mapping table is located using the instruction type label as an index. The memory address of the cache line segment containing the entry is found through the mapping table access path. An aligned store instruction is executed at the baseline overhead weight field to atomically write the protected baseline overhead weight. Immediately after the store instruction is completed, a cache line flush instruction is executed, using the cache line segment address as the operand, to write the current content of the cache line segment in the local cache back to main memory. An invalidation probe or update notification is broadcast to the cache coherence domain of all processor cores, ensuring that the newly written baseline overhead weight is immediately perceived by all other cores. Any subsequent query of the baseline overhead weight for this instruction type label will be able to read the data from this online write operation. Based on the foregoing embodiments, this invention provides a load monitoring device. The units and modules included in the device can be implemented by a processor in a computer device; of course, they can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.
[0167] Figure 2 This is a schematic diagram of the composition structure of a load monitoring device provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the load monitoring device 200 includes: The instruction processing module 210 is used to perform instruction type parsing processing on the player operation instruction stream accumulated in the current processing cycle at the beginning stage of the logical frame of the server main loop, and generate instruction type label sequence and instruction quantity information associated with instruction type label; The matching query module 220 is used to perform a matching query in a preset instruction-overhead mapping table using the instruction type label in the instruction type label sequence as an index, and obtain the baseline overhead weight corresponding to each instruction type label. The baseline overhead weight represents a pre-calibrated measure of the number of CPU cycles consumed to process a single instruction of that type. The load estimation module 230 is used to perform load estimation processing based on instruction quantity information and baseline overhead weights to generate a load estimation value for the logic frame to be processed. The load estimation value represents the predicted level of CPU cycle consumption within the logic frame to be processed. The hierarchical admission module 240 is used to perform hierarchical admission processing on instruction packets in the current processing cycle based on the comparison result between the load estimate and the single-frame logic processing budget. Instruction packets belonging to the non-critical instruction category are moved into the non-critical instruction temporary storage queue, and instruction packets belonging to the critical instruction category are submitted to the logic frame execution process. When the load estimate is detected to fall back to the preset safety threshold, the instruction packets in the non-critical instruction temporary storage queue are retrieved in batches and the processing is restored. The calibration update module 250 is used to actively inject standard instruction sequences into the logical frame execution process during periods when the server is in an idle load state, collect the actual execution time of the standard instruction sequence, compare the actual execution time with the baseline overhead weight of the corresponding instruction type label in the instruction-overhead mapping table, and perform online self-calibration update on the baseline overhead weight based on the result of the deviation comparison.
[0168] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided by the present invention can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of the present invention, please refer to the descriptions of the method embodiments of the present invention for understanding.
[0169] It should be noted that, in the embodiments of the present invention, if the above-described load monitoring method for game servers is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of the present invention, or the part that contributes to related technologies, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of the present invention are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.
[0170] Figure 3 A hardware entity diagram of a server provided in an embodiment of the present invention, such as... Figure 3 As shown, the hardware entity of the server 1000 includes a processor 1001 and a memory 1002, wherein the memory 1002 stores a computer program that can run on the processor 1001, and the processor 1001 executes the program to implement the steps in the method of any of the above embodiments.
[0171] The memory 1002 stores computer programs that can run on the processor. The memory 1002 is configured to store instructions and applications that can be executed by the processor 1001. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 1001 and various modules in the server 1000. It can be implemented by flash memory or random access memory (RAM).
[0172] When processor 1001 executes the program, it implements any of the steps of the load monitoring method applied to the game server described above. Processor 1001 typically controls the overall operation of server 1000.
[0173] This invention also provides a computer storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the load monitoring method for a game server as described in any of the above embodiments.
[0174] It should be noted that the descriptions of the above storage medium and device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of the present invention, please refer to the descriptions of the method embodiments of the present invention for understanding. The processor described above can be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understood that the electronic device implementing the above processor function can also be other types, and the embodiments of the present invention do not specifically limit it.
[0175] The above description is merely an embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.
Claims
1. A load monitoring method for game servers, characterized in that, Applied to a server, the method includes: At the beginning of the logical frame of the server's main loop, the accumulated player operation command stream in the current processing cycle is parsed to generate a command type label sequence and command quantity information associated with the command type label. Using the instruction type label in the instruction type label sequence as an index, a matching query is performed in the preset instruction-overhead mapping table to obtain the baseline overhead weight corresponding to each instruction type label. The baseline overhead weight represents a pre-calibrated metric of the number of CPU cycles consumed in processing a single instruction of that type. Based on the instruction quantity information and the baseline overhead weight, load estimation processing is performed to generate a load estimation value for the logic frame to be processed. The load estimation value represents the predicted level of CPU cycle consumption within the logic frame to be processed. Based on the comparison between the estimated load and the single-frame logic processing budget, instruction packets in the current processing cycle are subject to instruction classification and admission processing. Instruction packets belonging to the non-critical instruction category are moved into the non-critical instruction temporary storage queue, while instruction packets belonging to the critical instruction category are submitted to the logic frame execution process. When the estimated load is detected to fall back to the preset safety threshold, the instruction packets in the non-critical instruction temporary storage queue are retrieved in batches and restored for processing. During periods when the server is in an idle load state, standard instruction sequences are actively injected into the logical frame execution process. The actual execution time of the standard instruction sequences is collected, and the deviation of the actual execution time is compared with the baseline overhead weight of the corresponding instruction type label in the instruction-overhead mapping table. Based on the result of the deviation comparison, the baseline overhead weight is updated online by self-calibration.
2. The method according to claim 1, characterized in that, The step of using the instruction type labels in the instruction type label sequence as indexes to perform a matching query in a preset instruction-overhead mapping table to obtain the baseline overhead weight corresponding to each instruction type label includes: The instruction-overhead mapping table is stored in a memory region aligned with the processor cache line. The instruction type tag sequence is deduplicated and traversed. The instruction type tag that appears for the first time during the traversal is temporarily stored in the instruction tag deduplication register. After the traversal is completed, all instruction type tags temporarily stored in the instruction tag deduplication register are used as the set of independent instruction type tags for the current processing cycle. For each independent instruction type label in the set of independent instruction type labels, the processor's built-in cyclic redundancy check hardware instruction is invoked to process the string representation of the independent instruction type label, the fixed-length binary digest output by the hardware instruction is read, and the fixed-length binary digest is bitwise ANDed with the binary mask of the total number of slots in the instruction-overhead mapping table to obtain the probe starting slot index. Starting from the detection start slot index, read the status flag bit of the corresponding slot in the instruction-overhead mapping table. If the status flag bit indicates that the slot is valid, perform a bit-by-bit equality comparison between the fixed-length hash digest of the instruction type label stored in the slot and the fixed-length binary digest corresponding to the current independent instruction type label. If the bits are completely equal, load the baseline overhead weight in the slot into the processor general-purpose register. If the bit-by-bit equality comparison result is not equal, then a constant step size offset is performed on the probe starting slot index to obtain the next probe slot index, and the operation of reading the corresponding slot status flag bit is jumped to. When the number of probes reaches the preset probe limit, the preset conservative reference overhead weight is loaded into the processor general-purpose register, and a mapping missing event record for the current independent instruction type label is generated. The baseline overhead weights in the processor's general-purpose registers are stored in a weight buffer associated with the current independent instruction type label. After all independent instruction type label sets have been processed, the baseline overhead weights stored in the weight buffer are used as the baseline overhead weight set corresponding to the instruction type label sequence.
3. The method according to claim 2, characterized in that, The step of storing the instruction-overhead mapping table in a processor cache line-aligned memory region includes: During the static initialization phase of the game server process startup, a memory region with a size equal to the product of the expected capacity of the instruction-overhead mapping table and the width of a single entry is allocated through the memory alignment allocator, and the starting address of the requested memory region is aligned to the boundary of the processor's L1 cache line length; The memory region is divided into multiple cache line segments according to the processor cache line length. Each cache line segment stores all fields of a single table entry. When filling the table entry fields, if the total width of the fields does not fill a cache line segment, the end of the table entry is extended to the end address of the cache line segment by appending no-operation bytes. It is prohibited for a table entry to span two cache line segments. A cache line write-back control field is attached to each cache line segment within the memory region. The cache line write-back control field is used to indicate the ownership status of the cache line segment in the processor cache coherence protocol. When an entry is updated, the modified entry and the cache line write-back control field are written back to memory together by executing a storage instruction with write-back semantics. In the table entry read path, a processor data prefetch instruction is inserted. The data prefetch instruction uses the cache line segment address corresponding to the probe start slot index as the operand, loads the cache line segment from the main memory to the processor's last-level cache in advance, and marks it as a shared state. In the table entry update path, before modifying the baseline overhead weight within the table entry, an atomic swap instruction is executed to acquire exclusive ownership of the cache line, changing the state of the target cache line segment from a shared state to an exclusive modification state, and then downgrading the cache line segment to a shared state through a write-back operation after the modification is completed. A hardware performance monitoring event counter is allocated to each cache line segment in the memory region to record the frequency of cache miss events and remote cache access events occurring in that cache line segment. When the frequency of cache miss events exceeds a preset frequency limit, the corresponding entry in the cache line segment is relocated and moved to an empty slot.
4. The method according to claim 2, characterized in that, The step of loading a preset conservative baseline overhead weight into the processor general-purpose register when the number of probes reaches a preset probe limit, and generating a mapping missing event record for the current independent instruction type label, includes: When starting to perform a mapping table lookup on the independent instruction type label, a probe count register is initialized and set to 0. Each time the jump to the next probe slot is performed, the value of the probe count register is incremented by 1 and compared with the preset probe limit. When the value of the probe count register is equal to the preset probe limit, the mapping query for the independent instruction type label is temporarily blocked, and the pre-programmed conservative baseline overhead weight is retrieved from the processor's built-in read-only static storage area and loaded into the processor's general-purpose register. After loading the conservative baseline overhead weights into the processor general-purpose registers, a mapping missing event record is constructed. The mapping missing event record includes a fixed-length binary digest of the current independent instruction type label, the current timestamp count, and a snapshot of the slot occupancy ratio of the instruction-overhead mapping table at the current moment. The missing mapping event record is delivered to the asynchronous log recording thread through a lock-free single producer single consumer queue. The asynchronous log recording thread then serializes the missing mapping event record and writes it to the persistent storage device, and increments the global missing event counter. After the missing mapping event is triggered, the system queries the instruction-overhead mapping table to see if there is an empty slot with a status flag indicating that it is invalid. If there is an empty slot, the slot index of the empty slot is bound to the fixed-length binary digest of the current independent instruction type label, and the conservative baseline overhead weight is written into the baseline overhead weight field of the slot. At the same time, the status flag is set to valid. After writing the conservative baseline cost weight into the free slot, a mapping table expansion prompt containing the current independent instruction type label and the allocated slot index is reported to the server management interface, and the query process for the independent instruction type label is reset to reload the baseline cost weight from the free slot.
5. The method according to claim 1, characterized in that, The step of performing load estimation processing based on the instruction quantity information and the baseline overhead weight to generate a load estimation value for the logic frame to be processed includes: The current count value of the processor's timestamp counter is XORed bit by bit with the historical count value when the previous logical frame was completed. The continuous bit segment with the highest bit change rate is extracted and the bit segment is input to the entropy source input terminal of the processor's built-in hardware random number generator to provide entropy that depends on the processor clock jitter for instruction jitter smoothing. The number of instructions for each instruction type label in the instruction quantity information is processed using a sliding window average. The sliding window average takes the increment of the previous window average result and the new sample of the current window as input, outputs the updated window average result, and latches the result into the window average result register. The result in the window average result register and the baseline overhead weight of the corresponding instruction type label are respectively sent to the two source operand channels of the processor vector multiplication unit, and the vector multiplication unit is started to perform parallel multiplication and accumulation operation to obtain the cycle consumption contribution of a single type of instruction. All single-instruction cycle consumption contributions are sent to the processor vector reduction unit. The vector reduction unit performs multi-level reduction using a binary tree structure, merging the contributions corresponding to all instruction types within the same processing cycle into the total cycle consumption prediction. The actual number of CPU cycles consumed by the previous completed logical frame recorded in the performance monitoring unit is read and sent together with the total cycle consumption prediction corresponding to the previous completed logical frame to the processor differential comparator. The differential comparator outputs the deviation direction and amplitude signal and latches the signal to the deviation correction latch. The total cycle consumption prediction of the current logic frame is fused with the correction amount represented by the deviation direction and amplitude signals in the deviation correction latch, and the fusion result is written into the load prediction output register as the load prediction for the logic frame to be processed.
6. The method according to claim 5, characterized in that, The actual CPU cycles consumed by the previous completed logical frame, recorded in the read performance monitoring unit, along with the predicted total cycle consumption for the previous completed logical frame, are sent to the processor differential comparator, including: At the end of each logical frame execution, the CPU built-in performance monitoring unit is triggered to latch the number of CPU cycles counted during the duration of the logical frame into a model-specific register, and then sends a sampling completion signal to the processor interrupt controller, which routes the sampling completion signal to the load monitoring dedicated interrupt handling routine. In the load monitoring dedicated interrupt handling routine, a bulk data transfer instruction from the model-specific register to the memory buffer is executed, the latched CPU cycle number along with the frame sequence number of the current logical frame is written to the tail of the circular history buffer, and the write offset pointer of the buffer is atomically incremented. After generating a new total cycle consumption prediction, the CPU cycle count of the last written logical frame is read from the position indicated by the read offset pointer of the circular history buffer, and this CPU cycle count is used as the actual CPU cycle consumption count, and paired with the total cycle consumption prediction of the previous logical frame stored in the prediction history buffer. The actual CPU cycle consumption and the predicted total cycle consumption of the previous logic frame are written into the minuend latch and the subtrahend latch of the differential comparator, respectively, to enable the differential comparator to perform synchronous comparison. The output port of the differential comparator outputs the deviation direction signal and the deviation amplitude code. The deviation direction signal and deviation amplitude code are temporarily stored in the deviation correction latch, and the sign expansion logic of the deviation amplitude code is controlled according to the deviation direction signal. When the deviation direction signal indicates that the predicted amount is lower than the actual consumption, the deviation amplitude code is expanded to a positive correction amount, and vice versa. After the correction latch is completed, a lightweight write memory barrier instruction is issued to the processor to ensure that the contents of the deviation correction latch are visible to all processor cores before the subsequent load estimate fusion operation.
7. The method according to claim 5, characterized in that, The step of sending the cycle consumption contribution of all single-instruction types to the processor vector reduction unit, which performs multi-level reduction using a binary tree structure, merges the contribution of all instruction types within the same processing cycle into a total cycle consumption prediction, including: All the single-instruction cycle consumption contributions are packaged into a contribution vector aligned to the width of a vector register. If the number of contributions is less than the width of the vector register, the remaining channels in the vector register are filled with a neutral value representing zero consumption, and the filled contribution vector is loaded into the source vector register of the vector reduction unit. The contribution vector in the source vector register is read by the vector reduction unit. In the first stage of the reduction pipeline, the contribution vector is paired according to the odd and even of the channel index. Each pair of channels is reduced in parallel to merge the contributions of the two channels into a partial sum, resulting in a first-stage partial sum vector with half the length. The first-level partial sum and vector are fed into the second stage of the reduction pipeline, and the merging is performed according to the odd and even pairing of the channel index to produce the second-level partial sum and vector. This process is continued step by step until the final stage of the reduction pipeline outputs the final reduction result that occupies a single channel. The final reduction result is read from the vector register file, converted to a general integer register, and fused with the global coupling adjustment value corresponding to the current instruction combination obtained from the instruction type coupling adjustment table by processor integer multiplication. The fusion result is written to the total cycle consumption prediction register. After writing the fusion result to the total cycle consumption prediction register, a read-after-write hazard detection is performed on the register. If the register address is detected to match the address of an uncommitted write operation in the pipeline, the newly written fusion result is redirected to a new physical register through the register renaming mechanism.
8. The method according to claim 1, characterized in that, The step of performing instruction classification and admission processing on instruction packets within the current processing cycle based on the comparison result of the load estimate and the single-frame logic processing budget, moving instruction packets belonging to the non-critical instruction category into the non-critical instruction temporary storage queue, submitting instruction packets belonging to the critical instruction category to the logic frame execution flow, and when the load estimate is detected to have fallen back to a preset safety threshold, batch retrieving and restoring the instruction packets in the non-critical instruction temporary storage queue, includes: Write the load estimate and the single-frame logic processing budget into the source operand 1 register and source operand 2 register of the processor comparison unit, respectively, enable the comparison unit to perform unsigned integer comparison operation, read the condition code flag bit output by the comparison unit, and determine whether the load estimate exceeds the single-frame logic processing budget based on the condition code flag bit. When the estimated load exceeds the single-frame logic processing budget, each instruction packet in the instruction packet temporary storage area of the current processing cycle is traversed, the instruction type label at the fixed offset of the instruction packet header is extracted, the instruction type label is checked against the key instruction label set in the key instruction classification table, and the label existence check result is used to drive the selection signal of the instruction packet routing multiplexer. According to the selection signal, the instruction packet routing multiplexer routes instruction packets whose tag existence check result is not present in the critical instruction tag set to the non-critical instruction bypass buffer, and routes instruction packets whose tag existence check result is present in the critical instruction tag set to the logical frame submission buffer. In the non-critical instruction bypass buffer, a monotonically increasing sequence number generated by an atomic increment counter and the current system timestamp are appended to each received instruction packet to obtain a non-critical instruction temporary storage record. The non-critical instruction temporary storage record is then written into the non-critical instruction temporary storage queue through a lock-free tail pointer update operation. After submitting the instruction for the current logical frame, continuously monitor the load estimate of subsequent logical frames. When it is detected that the load estimate does not exceed the preset safety threshold within several consecutive logical frames, start from the head of the non-critical instruction temporary storage queue and pop the non-critical instruction temporary storage records in batches according to the ascending order of the monotonically increasing sequence number. For the popped-up non-critical instruction temporary records, the attached monotonically increasing sequence number and system timestamp are stripped to recover the original instruction packet. The recovered instruction packet is then merged into the header of the instruction packet temporary storage area of the next logic frame to be processed, while maintaining the original arrival order of each instruction packet.
9. A server comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 8.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 8.