Dynamic logical mapping preloading and memory scheduling method based on priority token

Abstract

The present application relates to computer system memory management technical field, specifically, a kind of dynamic logic mapping preloading and memory scheduling method based on priority token, including the following steps: S1, generating preloading token with priority identification;S2, memory area is dynamically partitioned according to service level;S3, token admission decision and dynamic mapping establishment;S4, differential I / O response path.Compared with prior art, by encapsulating preloading request as token carrying priority identification and prediction confidence, and introducing token admission decision mechanism based on real-time load pressure index, traditional "predicted after direct loading" is changed into "controlled resource reservation based on service level", fundamentally solve the problem of the lack of cooperation between preloading and memory management.The establishment of temporary privilege mapping and the automatic recycling mechanism based on TTL further realize the active management of memory resources and the deterministic data life cycle control.

Description

Technical Field

[0001] This invention relates to the field of computer system memory management technology, specifically a method for dynamic logical mapping preloading and memory scheduling based on priority tokens. Background Technology

[0002] Currently, HMB (Host Memory Buffer) caching technology has become a key means to improve system performance. However, existing solutions, such as the Chinese invention patent with publication number CN119883129A, all rely on static LBA (Static Logical Block Address) mapping caching mechanisms. These solutions have significant limitations: firstly, they cannot dynamically adapt to different application scenarios, such as the access patterns of game loading and video editing, leading to low caching efficiency; secondly, they lack dynamic partitioning logic for critical mapping areas, making it difficult to prioritize the real-time performance of core data. For example, in game loading scenarios, static mapping cannot predict frequently accessed texture data, resulting in a significant increase in loading latency.

[0003] Furthermore, even a simple combination of existing dynamic preloading technology and memory partitioning technology still has deep technical flaws: aggressive preloading strategies may load data blocks from non-core applications into critical mapping areas where core applications reside, causing cache pollution and performance interference; at the same time, existing preloaded data lacks clear lifecycle management, resulting in invalid data occupying memory for extended periods without timely reclamation, which further exacerbates memory thrashing under mixed loads. These problems essentially stem from the lack of a Quality of Service (QoS)-aware collaborative adjudication mechanism between preloading and memory management, meaning that it is impossible to perform admission control and dynamic resource reservation scheduling for each preloading operation based on real-time memory pressure and the priorities of each application. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, this invention provides a method for dynamic logic-to-physical mapping preloading and collaborative scheduling based on priority tokens.

[0005] To achieve the above objectives, a dynamic logical mapping preloading and memory scheduling method based on priority tokens is designed, including the following steps: S1, Generate a preload token with priority identifier: Obtain historical IO access data, output the logical address of the data block that may be accessed in the future through the prediction model, and extract the priority feature of the corresponding application from the historical I / O access data to generate a preload token for each predicted data block. The preload token carries the priority identifier and prediction confidence of the data block. S2, memory regions are dynamically partitioned according to service level: the host physical memory is divided into multiple service level regions, and the current load pressure index and available capacity of each region are collected in real time; S3, Token Admission Decision and Dynamic Mapping Establishment: The memory scheduler receives the preloaded token and, based on the priority identifier, prediction confidence level, and the current load pressure index of each memory region, performs a token admission decision—only when the priority identifier of the token is not lower than the current minimum admission priority of the target region, and the available capacity of the target region is sufficient to accommodate the data block, will a physical memory address be allocated to the token, and a temporary privileged mapping from the logical address LBA of the data block to the allocated physical memory address PBA will be dynamically established; otherwise, the token will be downgraded or discarded. S4, Differentiated I / O response path: When an application initiates an actual I / O request, it first queries the temporary privileged mapping. If a match is found, data access is completed directly through the mapping; if a match is not found, access is completed through the operating system's general storage stack.

[0006] The specific method for training the prediction logic in step S1 is as follows: historical data is input into the machine learning model, and the model analyzes the access behavior in real time to generate an initial preloading instruction; the prediction confidence is output by the prediction model during inference, representing the probability that the data block will be accessed within a future time window; the priority feature is an identifier extracted from the application access log that characterizes the criticality level of the application, including at least one of application I / O latency sensitivity and CPU affinity label; the machine learning model is selected from either a lightweight decision tree model or a lightweight neural network model.

[0007] In step S1, the specific method for obtaining historical data is as follows: real-time monitoring of application access logs and extraction of feature parameters; the data obtained from monitoring application access logs includes I / O request sequences, access frequency, and access patterns; the extracted feature parameters include block size and access interval.

[0008] In step S2, the host memory is divided into: The highest priority critical mapping area: exclusively allocated to core applications, with the highest access priority; The ordinary cache area in the middle of the priority: shared and allocated to non-core applications, with intermediate admission priority; The lowest priority backup area: used for temporary data storage, with the lowest access priority; The load stress index is a weighted normalized value of regional memory occupancy and average I / O response latency.

[0009] The specific method for token admission adjudication in step S3 is as follows: when the token carries the priority identifier of the corresponding core application, the application for the key mapping area, the ordinary cache area, or the backup area is allowed; when the token carries the priority identifier of the corresponding non-core application, the application for the ordinary cache area or the backup area is only allowed; and when the load pressure index of the target area exceeds the preset threshold, only tokens carrying the priority identifier of the corresponding core application are allowed to be admitted; the downgrade process in step S3 includes: reducing the priority identifier of the token and re-entering it into the adjudication queue, or eliminating the priority identifier of the token so that it is only used as a regular pre-read prompt.

[0010] The preloaded token mentioned in step S1 also carries a Time-to-Live (TTL); the temporary privilege mapping established in step S3 is only valid within the TTL, and is automatically removed after the timeout, and the allocated physical memory address is reclaimed.

[0011] In step S2, the area size is adjusted in real time through a feedback mechanism. The data collected by the feedback mechanism includes application response time, memory usage, and remaining memory space. The feedback mechanism further collects the average token admission rate and mapping hit rate of each area, and performs area capacity reallocation with the goal of minimizing the admission rejection rate of key mapping areas.

[0012] The temporary privileged mapping described in step S3 is stored in physical memory as a page table or mapping cache line independent of the operating system. The hardware I / O path can directly access the data through this mapping, bypassing the host operating system's general storage software stack.

[0013] The prediction confidence level mentioned in step S1 is output by the prediction model during inference, representing the probability that the data block will be accessed within a future time window; in the token admission decision in step S3, for tokens with the same priority identifier, the token with the higher prediction confidence level is given priority admission.

[0014] To achieve the above objectives, a system for executing the above method is designed, comprising: Token generation engine: Real-time monitoring of application access logs, extraction of feature parameters, and generation of preloaded tokens carrying priority identifiers and prediction confidence through a lightweight decision tree model; Memory priority tiering module: Divides host memory into multi-level priority regions, dynamically adjusts region size, and calculates and publishes the load pressure index and available capacity of each region in real time; Token admission and dynamic mapping module: Receives the preloaded token issued by the token generation engine, combines it with the region status information issued by the memory priority hierarchical module, performs token admission adjudication, dynamically establishes a temporary privilege mapping from LBA to PBA for admitted tokens, and downgrades or discards unadmitted tokens. Coordinated scheduling module: Based on a priority queue task distribution mechanism, it coordinates memory resource allocation; I / O Fast Path Unit: Coupled to the front end of the storage stack, it is used to intercept application I / O requests, prioritize querying the temporary privileged mapping, and return data directly from the mapping when a match is found, and pass the request to the regular I / O path when a match is not found.

[0015] Compared with existing technologies, this invention encapsulates preloading requests into tokens carrying priority identifiers and prediction confidence levels, and introduces a token admission adjudication mechanism based on real-time load pressure indices. This transforms the traditional "direct loading after prediction" into "service level-based controlled resource reservation," fundamentally solving the problem of lack of coordination between preloading and memory management. The establishment of temporary privileged mappings and the TTL-based automatic reclamation mechanism further realize proactive management of memory resources and deterministic data lifecycle control. Intelligent allocation of cache resources is achieved without additional hardware; mapping strategies can be dynamically adjusted during system runtime, significantly improving data access efficiency and system response speed. Detailed Implementation

[0016] The present invention will now be further described.

[0017] The dynamic logic mapping preloading and memory scheduling method in this embodiment includes the following steps: S1, Generate a preload token with priority identifier: Obtain historical IO access data, output the logical address of data blocks that may be accessed in the future through the prediction model, extract the priority features of the corresponding application from the historical I / O access data, and generate a preload token for each predicted data block. The preload token carries the priority identifier and prediction confidence of the data block.

[0018] The specific method for obtaining historical data is as follows: monitor application access logs in real time and extract characteristic parameters. The data obtained from monitoring application access logs includes I / O request sequences, access frequency, and access patterns, such as sequential read / write and random access; the extracted characteristic parameters include block size and access interval.

[0019] The specific method for training the prediction logic is as follows: historical data is input into the machine learning model, and the model analyzes access behavior in real time to generate initial pre-loading instructions to adapt to different scenarios. The machine learning model used is either a lightweight decision tree model or a lightweight neural network model.

[0020] Unlike traditional methods, in this step, the predictive model simultaneously outputs two pieces of information during inference: first, the probability that each logical block address will be accessed within the future time window, i.e., the prediction confidence; and second, priority features extracted from the application access logs that characterize the application's criticality level, including at least one of application I / O latency sensitivity and CPU affinity tags. The token encapsulation unit encapsulates the above information into a preloaded token. A typical token data structure includes the following fields: unique token identifier, target data block LBA, priority identifier (priority identifier for core applications / priority identifier for non-core applications), prediction confidence, time-to-live (TTL), and token generation timestamp. The initial value of TTL is dynamically set according to the current overall system load; under high load, the TTL is shortened overall to accelerate the reclamation of expired tokens.

[0021] For example, if the same block is accessed three times in a row, it is predicted that the adjacent block will be accessed, and a token carrying the priority identifier of the application is generated. The target LBA is 0x1000-0x2000, the confidence level is 0.85, and the TTL is 5000 clock cycles.

[0022] S2, Memory regions are dynamically partitioned according to service level: The host physical memory is divided into multiple service level regions, and the current load pressure index and available capacity of each region are collected in real time.

[0023] The highest priority critical mapping area: exclusively allocated to core applications, prioritizing the real-time performance of core applications, and having the highest access priority; The ordinary cache area in the middle of the priority: shared and allocated to non-core applications, with intermediate admission priority; The lowest priority spare area: used for temporary data storage, with the lowest admission priority.

[0024] In this embodiment, the initial size of the critical mapping area is 20MB, the ordinary cache area is 50MB, and the remaining memory is a spare area.

[0025] In step S2, core applications and non-core applications are distinguished using the following method: S21, The historical data obtained in real-time monitoring in step S1, including I / O request sequence, access frequency, access mode, block size and access interval feature parameters, are processed by machine learning model to generate a real-time priority score for each application or each I / O stream. S22, compare the real-time priority score with a set threshold. If the score is higher than the set threshold, it is determined to be a core application; if the score is lower than the set threshold, it is determined to be a non-core application.

[0026] In step S21, the I / O request sequence, access frequency, access mode, block size, and access interval feature parameters obtained from real-time monitoring in step S1 are input into the machine learning model. The machine learning model outputs a real-time priority score between 0 and 1 for each application or each I / O stream. The higher the score, the higher the real-time requirement of the application or data stream, and the more priority it should be given.

[0027] In practical use, the threshold is set and adjusted in real time based on the application response time, memory usage, and remaining memory space collected by the feedback mechanism: when the memory usage increases or the application response time is prolonged, the dynamic threshold is increased so that fewer applications are identified as core applications.

[0028] For example, when system memory usage increases, such as exceeding 80%, or application response time increases, such as exceeding 100ms, it indicates that system resources are strained. In this case, the dynamic threshold is increased, for example from 0.6 to 0.75, so that only a few applications with the highest real-time requirements can be identified as core applications, thereby ensuring the real-time performance of critical tasks. When there is sufficient remaining memory and application response time is short, the dynamic threshold is decreased, for example from 0.6 to 0.4, allowing more applications to be identified as core applications, so as to make full use of cache resources and improve overall performance.

[0029] In step S21, the calculation of the real-time priority score is based on one or more of the following: The higher the proportion of I / O requests with an average access interval of less than 10 milliseconds, the higher the score. The higher the proportion of I / O requests with a block size of less than 64KB and that are random access, the higher the score. Whether the application is in a foreground interactive state; if it is a foreground application, the score is increased by a fixed weight, such as 0.2. The predicted amount of data to be accessed within the next 100 milliseconds; the higher the predicted access volume, the higher the score.

[0030] The more criteria that meet the above conditions, or the higher their weight, the higher the real-time priority score. For example, a foreground game application with an average access interval of 5 milliseconds for texture loading requests, a block size of 32KB and random access, and a prediction that approximately 5MB of data needs to be loaded within the next 100ms, can have a real-time priority score of 0.85. In contrast, a background log writing application with an access interval greater than 500 milliseconds and sequential access with a block size of 1MB will only have a score of 0.12.

[0031] In this step, the load stress index and available capacity of each region are also collected in real time. The load stress index is a weighted normalized value of region memory utilization and average I / O response latency, calculated as: LPI = 0.7 × (current utilization / total region capacity) + 0.3 × (normalized average I / O response latency). The LPI range is [0, 1]. When the LPI exceeds 0.8, the region is considered to be under high pressure. The LPI and available capacity of each region are published in real time through shared memory for use in the token admission decision in step S3.

[0032] In step S2, the region size is adjusted in real time through a feedback mechanism. The feedback mechanism collects data including application response time, memory usage, and remaining memory space. When the application response time is long or the memory usage is high, the memory size of that region is increased accordingly based on the remaining memory space, while the size of other regions is reduced, prioritizing the highest priority critical mapping region to avoid resource contention. Furthermore, the feedback mechanism further collects the average token admission rate and mapping hit rate of each region, aiming to minimize the admission rejection rate of the critical mapping region during region capacity reallocation. When the admission rejection rate of the critical mapping region exceeds 15% for three consecutive statistical periods, memory pages are allocated from the ordinary cache or spare area to supplement the critical mapping region.

[0033] S3, Token Admission Decision and Dynamic Mapping Establishment: The memory scheduler receives the preloaded token and, based on the priority identifier, prediction confidence level, and the current load pressure index of each memory region, performs a token admission decision—only when the priority identifier of the token is not lower than the current minimum admission priority of the target region, and the available capacity of the target region is sufficient to accommodate the data block, will a physical memory address be allocated to the token, and a temporary privileged mapping from the logical address LBA of the data block to the allocated physical memory address PBA will be dynamically established; otherwise, the token will be downgraded or discarded.

[0034] As a preferred token application area rule, tokens carrying core application priority identifiers are allowed to apply for mapping establishment in the critical mapping area, ordinary cache area, or backup area; tokens carrying non-core application priority identifiers are only allowed to apply for mapping establishment in the ordinary cache area or backup area, and are not allowed to apply for the critical mapping area. Furthermore, when the load pressure index of the target area exceeds a preset threshold, only tokens carrying the corresponding core application priority identifier are allowed to enter.

[0035] The specific method is as follows: The memory scheduler maintains a priority-sorted queue of pending tokens. The queue sorting rules are: priority is prioritized by priority identifier, with core application priority identifiers being higher than non-core application priority identifiers. Within the same priority, tokens are sorted from highest to lowest predicted confidence. The arbitrator retrieves a token from the head of the queue and executes the following arbitration logic based on the load pressure index of the target region: When the target area LPI > 0.8, only tokens carrying the core application priority identifier are allowed to be admitted; When 0.5 < LPI ≤ 0.8, tokens carrying priority identifiers of core applications and non-core applications are allowed to be admitted; When LPI ≤ 0.5, all priority tokens are allowed to be admitted.

[0036] After a token is successfully admitted, the dynamic mapper immediately establishes a temporary privilege mapping for the token. The mapping is stored in a mapping table independent of the operating system, and is recorded in the form of key-value pairs: Key is the LBA of the data block, and Value is the allocated PBA and TTL deadline. The query interface of the mapping table is directly exposed to the hardware I / O path. The system clock interrupt handler periodically scans the mapping table, automatically deletes all expired mapping entries, and recycles the corresponding physical memory addresses to the space pool of the corresponding region.

[0037] Tokens that fail the arbitration shall be degraded: their priority identifiers shall be lowered, for example, from core application priority to non-core application priority, or from non-core application priority to a normal read-ahead prompt without a priority identifier, and then put back into the arbitration queue; or their priority identifiers shall be directly removed so that the token only serves as a normal read-ahead prompt, written into a low-priority read-ahead prompt queue, and only consumed during the system idle period.

[0038] The multi-level scheduler allocates tasks to corresponding memory layers based on the priority queue task distribution mechanism, dynamically balancing preloading and background tasks. For example, high-priority tasks are directly allocated to the key mapping area to ensure real-time performance, such as game rendering; medium-priority tasks are allocated to the normal cache area to balance performance and resource occupation, such as video decoding; low-priority tasks are allocated to the standby area to avoid interfering with core tasks, such as log writing.

[0039] The preload token described in step S1 further carries a time-to-live TTL; the temporary privilege mapping established in step S3 is only valid within the TTL, is automatically removed after timeout, and the allocated physical memory addresses are recycled.

[0040] The temporary privilege mapping described in step S3 is stored in the physical memory as a page table or a mapping cache line independent of the operating system, and the hardware I / O path can directly access data through this mapping, bypassing the general storage software stack of the host operating system.

[0041] The prediction confidence described in step S1 is output by the prediction model during inference, which represents the probability that the data block will be accessed within a future time window; in the token admission arbitration of step S3, for tokens with the same priority identifier, tokens with higher prediction confidence are admitted first.

[0042] S4, Differentiated I / O response path: When an application initiates an actual I / O request, it first queries the temporary privileged mapping. If a match is found, data access is completed directly through the mapping; if a match is not found, access is completed through the operating system's general storage stack.

[0043] Specifically, when an application initiates a read I / O request, the I / O fast path unit intercepts the request and first queries the temporary privileged mapping table established in step S3 using the requested logical address as the key. If a match is found, the physical address is directly obtained from the mapping entry, and the data is transferred to the application buffer via direct memory access (DMA), without needing to enter the general file system or block device layer of the operating system kernel. If a match is not found, the I / O request is forwarded to the general storage software stack of the host operating system and processed according to the regular I / O process.

[0044] The system for the aforementioned dynamic logic mapping preloading and memory scheduling method includes: Token generation engine: Real-time monitoring of application access logs, extraction of feature parameters, and generation of preloaded tokens carrying priority identifiers and prediction confidence through a lightweight decision tree model; Memory priority tiering module: Divides host memory into multi-level priority regions, dynamically adjusts region size, and calculates and publishes the load pressure index and available capacity of each region in real time; Token admission and dynamic mapping module: Receives the preloaded token issued by the token generation engine, combines it with the region status information issued by the memory priority hierarchical module, performs token admission adjudication, dynamically establishes a temporary privilege mapping from LBA to PBA for admitted tokens, and downgrades or discards unadmitted tokens. Coordinated scheduling module: Based on a priority queue task distribution mechanism, it coordinates memory resource allocation; I / O Fast Path Unit: Coupled to the front end of the storage stack, it is used to intercept application I / O requests, prioritize querying the temporary privileged mapping, and return data directly from the mapping when a match is found, and pass the request to the regular I / O path when a match is not found.

[0045] This invention features an application behavior prediction mechanism that integrates a lightweight machine learning model to analyze application access patterns in real time and dynamically generate preload tokens carrying priority identifiers. Furthermore, by dividing host memory into multi-level priority regions and employing an exclusive allocation strategy for critical regions, the real-time performance of core applications is ensured. Unlike the traditional "predict and load directly" approach, this invention introduces a token admission adjudication mechanism, transforming each preload operation into a resource reservation request constrained by real-time memory load pressure. Only tokens that pass the adjudication are established with temporary privilege mappings, and proactive recycling based on TTL is implemented. Through I / O fast path units, data access that hits the mapping can completely bypass the operating system kernel software stack, achieving hardware-level low-latency response. A multi-level scheduler, based on a priority queue-based task distribution mechanism, coordinates the resource allocation of CPU, memory, and storage devices.

[0046] Through practical testing, it has been verified that this invention can significantly improve system performance and resource utilization in typical application scenarios, with the specific effects as follows: 1. Performance improvements and latency optimization: In game loading scenarios, by preloading frequently accessed texture data, this invention reduces game resource loading time by 40% and improves frame rate stability by 25%. For example, in open-world games, stuttering during player character movement is reduced by 60%, and system response speed is improved by 30%.

[0047] In video editing scenarios, by predicting continuous frame access patterns, this invention reduces video editing latency by 50% and improves export efficiency by 20%. For example, in 4K video editing, the latency of timeline dragging operations is reduced from 200ms to 100ms, significantly improving the user experience.

[0048] 2. Optimize resource utilization: In terms of memory allocation efficiency, dynamic memory tiering reduces the memory footprint of critical applications by 30% and increases the overall system throughput by 15%. For example, in multi-tasking scenarios, the memory footprint of the game engine drops from 1.2GB to 0.8GB, while the memory allocation of background services remains unaffected.

[0049] Regarding improving cache hit rate, this invention optimizes the preloading strategy through a predictive model, increasing the HMB cache hit rate from 65% to 85% and reducing the number of I / O requests. For example, in database query scenarios, after the cache hit rate is improved, the number of disk I / O operations decreases by 40%, and system throughput increases by 25%.

[0050] 3. Enhanced system stability: In terms of adaptability to high concurrency loads, the collaborative scheduling framework reduces the system's crash rate by 80% and shortens task response time by 30% under high concurrency loads. For example, in a server scenario with 1000 concurrent users, the system crash rate drops from 5% to 1%, and the average task response time drops from 200ms to 140ms.

[0051] Regarding dynamic scenario adaptability, this invention adjusts memory tiering and mapping strategies in real time through a feedback mechanism, enabling the system to maintain stable performance in different application scenarios, such as games, videos, and databases. For example, in mixed load scenarios, the system dynamically adjusts the size of the critical area to prioritize the real-time performance of core tasks while avoiding resource contention for non-critical tasks.

[0052] 4. Comparison of scene-based effects: In game loading scenarios, the traditional static LBA mapping method requires 3.2 seconds of loading time; using the method of this invention, the loading time is reduced to 1.9 seconds, a 40% reduction, and the frame rate is increased by 25%. In video editing scenarios, the traditional static LBA mapping method results in an editing latency of 200ms; using the method of this invention, the editing latency is reduced to 100ms, a 50% reduction, and an improvement in export efficiency of 20%. In database query scenarios, the traditional static LBA mapping method has a cache hit rate of 65%, while the method of this invention has a cache hit rate of 85%, which is a 20% improvement and a 40% reduction in I / O operations.

[0053] In high-concurrency server scenarios, the traditional static LBA mapping method results in a 5% crash rate, while the method of this invention reduces the crash rate to 1%, a reduction of 80%, and shortens the response time by 30%.

[0054] In one embodiment of the present invention, applying the present invention to game loading scene optimization includes the following steps: S1, Generate a preload token with priority identifier: When the game starts, the algorithm analyzes historical access logs, such as the loading order of texture and model data, predicts high-frequency access blocks, extracts the priority features of the game engine, generates a preload token carrying the priority identifier of the core application, and sets the TTL to 5000 clock cycles.

[0055] S2, memory priority tiering: divides host memory into critical and normal areas; the critical area is exclusively allocated to the game engine to ensure low-latency access to real-time rendering data.

[0056] S3, Token Admission Adjudication and Dynamic Mapping: The memory scheduler adjudicates game engine-related tokens. Since the load pressure index of the critical mapping area is below a threshold, all tokens are admitted. Based on the prediction results, a temporary privileged mapping is dynamically established to map player character data to the physical memory of the critical area, avoiding fragmented access caused by static LBA, and tasks are assigned to the corresponding memory tiers. Tokens generated by low-priority applications such as background log writes are rejected or downgraded to the backup area when the pressure in the critical area increases, avoiding cache pollution.

[0057] S4, Differentiated I / O Response Path: When the game engine initiates a rendering data read request, it first queries the temporary privileged mapping. If a match is found, the data is directly obtained through DMA, bypassing the operating system file system stack.

[0058] During game loading, the size of the critical mapping area is adjusted in real time based on data such as application response time, memory usage, and remaining memory space collected by the feedback mechanism to reduce background task interference. After the token TTL expires, the temporary privilege mapping is automatically removed and the memory pages are recycled to the critical area space pool.

[0059] Tests show that this solution significantly reduces game loading time and improves frame rate stability.

Claims

1. A method for dynamic logical mapping preloading and memory scheduling based on priority tokens, characterized in that: The steps include the following: S1, Generate a preload token with priority identifier: Obtain historical IO access data, output the logical address of the data block that may be accessed in the future through the prediction model, and extract the priority feature of the corresponding application from the historical I / O access data to generate a preload token for each predicted data block. The preload token carries the priority identifier and prediction confidence of the data block. S2, memory regions are dynamically partitioned according to service level: the host physical memory is divided into multiple service level regions, and the current load pressure index and available capacity of each region are collected in real time; S3, Token Admission Decision and Dynamic Mapping Establishment: The memory scheduler receives the preloaded token and, based on the priority identifier, prediction confidence level, and the current load pressure index of each memory region, performs a token admission decision—only when the priority identifier of the token is not lower than the current minimum admission priority of the target region, and the available capacity of the target region is sufficient to accommodate the data block, will a physical memory address be allocated to the token, and a temporary privileged mapping from the logical address LBA of the data block to the allocated physical memory address PBA will be dynamically established; otherwise, the token will be downgraded or discarded. S4, Differentiated I / O response path: When an application initiates an actual I / O request, it first queries the temporary privileged mapping. If a match is found, data access is completed directly through the mapping; if a match is not found, access is completed through the operating system's general storage stack.

2. The method according to claim 1, characterized in that: The specific method for training the prediction logic in step S1 is as follows: historical data is input into the machine learning model, and the model analyzes the access behavior in real time to generate an initial preloading instruction; the prediction confidence is output by the prediction model during inference, representing the probability that the data block will be accessed within a future time window; the priority feature is an identifier extracted from the application access log that characterizes the criticality level of the application, including at least one of application I / O latency sensitivity and CPU affinity label; the machine learning model is selected from either a lightweight decision tree model or a lightweight neural network model.

3. The method according to claim 1, characterized in that: In step S1, the specific method for obtaining historical data is as follows: real-time monitoring of application access logs and extraction of feature parameters; the data obtained from monitoring application access logs includes I / O request sequences, access frequency, and access patterns; the extracted feature parameters include block size and access interval.

4. The method according to claim 1, characterized in that: In step S2, the host memory is divided into: The highest priority critical mapping area: exclusively allocated to core applications, with the highest access priority; The ordinary cache area in the middle of the priority: shared and allocated to non-core applications, with intermediate admission priority; The lowest priority backup area: used for temporary data storage, with the lowest access priority; The load stress index is a weighted normalized value of regional memory occupancy and average I / O response latency.

5. The method according to claim 4, characterized in that: The specific method for token access decision in step S3 is as follows: when the token carries the priority identifier of the corresponding core application, the application for the key mapping area, ordinary cache area or backup area is allowed; when the token carries the priority identifier of the corresponding non-core application, the application for the ordinary cache area or backup area is only allowed; and when the load pressure index of the target area exceeds the preset threshold, only tokens carrying the priority identifier of the corresponding core application are allowed to access. The downgrade process described in step S3 includes: reducing the priority identifier of the token and re-entering it into the adjudication queue, or removing the priority identifier of the token so that it is only used as a regular read-ahead prompt.

6. The method according to claim 1, characterized in that: The preloaded token mentioned in step S1 also carries a Time-to-Live (TTL); the temporary privilege mapping established in step S3 is only valid within the TTL, and is automatically removed after the timeout, and the allocated physical memory address is reclaimed.

7. The method according to claim 1, characterized in that: In step S2, the area size is adjusted in real time through a feedback mechanism. The data collected by the feedback mechanism includes application response time, memory usage, and remaining memory space. The feedback mechanism further collects the average token admission rate and mapping hit rate of each area, and performs area capacity reallocation with the goal of minimizing the admission rejection rate of key mapping areas.

8. The method according to claim 1, characterized in that: The temporary privileged mapping described in step S3 is stored in physical memory as a page table or mapping cache line independent of the operating system. The hardware I / O path can directly access the data through this mapping, bypassing the host operating system's general storage software stack.

9. The method according to claim 1, characterized in that: The prediction confidence level mentioned in step S1 is output by the prediction model during inference, representing the probability that the data block will be accessed within a future time window; in the token admission decision in step S3, for tokens with the same priority identifier, the token with the higher prediction confidence level is given priority admission.

10. A system for performing the method according to any one of claims 1 to 9, characterized in that, include: Token generation engine: Real-time monitoring of application access logs, extraction of feature parameters, and generation of preloaded tokens carrying priority identifiers and prediction confidence through a lightweight decision tree model; Memory priority tiering module: Divides host memory into multi-level priority regions, dynamically adjusts region size, and calculates and publishes the load pressure index and available capacity of each region in real time; Token admission and dynamic mapping module: Receives the preloaded token issued by the token generation engine, combines it with the region status information issued by the memory priority hierarchical module, performs token admission adjudication, dynamically establishes a temporary privilege mapping from LBA to PBA for admitted tokens, and downgrades or discards unadmitted tokens. Coordinated scheduling module: Based on a priority queue task distribution mechanism, it coordinates memory resource allocation; I / O Fast Path Unit: Coupled to the front end of the storage stack, it is used to intercept application I / O requests, prioritize querying the temporary privileged mapping, and return data directly from the mapping when a match is found, and pass the request to the regular I / O path when a match is not found.