Memory management method and device for secure container

Abstract

The embodiment of the invention discloses a memory management method and device for a secure container. The specific implementation mode of the method comprises the steps that a mounting point of the virtual file system is created according to preset mounting parameters, and the mounting parameters comprise an identifier used for indicating whether a large-page memory is started or not; creating a security container, and setting the virtual file system as a memory rear-end carrier of the security container through the virtual machine simulator; detecting mounting parameters through the virtual machine simulator to determine whether a large page memory is started or not; in response to determining to enable the large page memory, allocation of the large page memory is requested. According to the implementation mode, refined application of a transparent large page technology in a secure container environment is realized, and performance benefits close to static large pages are obtained while dynamic memory management advantages are kept.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a method and apparatus for memory management of secure containers. Background Technology

[0002] Secure containers, due to their inherent isolation, are often used in cloud-native hybrid deployment scenarios. In addition, large page memory can improve memory access performance, reduce memory management overhead, and decrease page faults. Current secure containers that enable large page memory rely on traditional large pages, requiring a predetermined number of large pages to be configured beforehand. Summary of the Invention

[0003] The embodiments of this disclosure provide a method and apparatus for memory management of secure containers.

[0004] In a first aspect, embodiments of this disclosure provide a memory management method for a secure container, comprising: creating a mount point for a virtual file system according to preset mount parameters, wherein the mount parameters include an identifier for indicating whether massive page memory is enabled; creating a secure container and setting the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator; detecting the mount parameters through the virtual machine emulator to determine whether massive page memory is enabled; and requesting the allocation of massive page memory in response to determining that massive page memory is enabled.

[0005] In some embodiments, requesting the allocation of large page memory includes: calculating the number of large pages based on the total memory and the large page size; and requesting the allocation of contiguous memory blocks based on the large page size and the number of large pages.

[0006] In some embodiments, requesting the allocation of large page memory further includes: determining the large page size based on large page configuration information and hardware support capabilities.

[0007] In some embodiments, the method further includes: constructing a page table structure for the client; loading the page table structure into the client's virtual address space, enabling the client to access contiguous memory blocks through the page table structure.

[0008] In some embodiments, the method further includes: identifying unoccupied fragmented memory pages; and merging the fragmented memory pages into large pages in response to detecting that the total capacity of the fragmented memory pages has reached a preset size.

[0009] In some embodiments, the method further includes: monitoring at least one of the following performance metrics of memory: memory access latency, TLB hit rate, memory fragmentation rate, and memory bandwidth utilization; adjusting the identifier according to the performance metrics; and reclaiming unused large page memory.

[0010] In some embodiments, the method further includes: detecting the memory access pattern of the client workload; and dynamically adjusting the large page size used based on the memory access pattern.

[0011] Secondly, embodiments of this disclosure provide a memory management device for a secure container, comprising: a mounting unit configured to create a mount point for a virtual file system according to preset mounting parameters, wherein the mounting parameters include an identifier for indicating whether massive page memory is enabled; a creation unit configured to create a secure container and set the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator; a detection unit configured to detect the mounting parameters through a virtual machine emulator to determine whether massive page memory is enabled; and an allocation unit configured to request the allocation of massive page memory in response to determining that massive page memory is enabled.

[0012] In some embodiments, the allocation unit is further configured to: calculate the number of large pages based on the total memory and the large page size; and request the allocation of contiguous memory blocks based on the large page size and the number of large pages.

[0013] In some embodiments, the allocation unit is further configured to determine the large page size based on large page configuration information and hardware support capabilities.

[0014] In some embodiments, the apparatus further includes a page table building unit configured to: build a page table structure for the client; load the page table structure into the client's virtual address space, enabling the client to access contiguous memory blocks through the page table structure.

[0015] In some embodiments, the apparatus further includes a merging unit configured to: identify unoccupied fragmented memory pages; and merge the fragmented memory pages into large page memory in response to detecting that the total capacity of the fragmented memory pages has reached a preset size.

[0016] In some embodiments, the device further includes a monitoring unit configured to: monitor at least one of the following performance metrics of the memory: memory access latency, TLB hit rate, memory fragmentation rate, and memory bandwidth utilization; adjust the identifier according to the performance metrics; and reclaim unused large page memory.

[0017] In some embodiments, the apparatus further includes a detection unit configured to: detect the memory access pattern of the client workload; and dynamically adjust the large page size used based on the memory access pattern.

[0018] Thirdly, embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more computer programs stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform the method as described in any one of the first or second aspects.

[0019] Fourthly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method as described in any one of the first or second aspects.

[0020] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, implements the method as described in any one of the first or second aspects.

[0021] Current secure container memory management faces two key bottlenecks: First, traditional 4KB small page management leads to increased TLB (Translation Lookaside Buffer) miss rates and significantly increased memory access latency, creating a performance bottleneck, especially in memory-intensive applications. Second, traditional big page technology requires static pre-allocation of fixed memory, while transparent big page technology, although supporting dynamic merging, has the drawback of only supporting global enabling at the host level and the QEMU (Quick EMUlator, a virtual operating system emulator used to provide lightweight virtualization to isolate containers) virtualization layer being unable to recognize the underlying big page memory.

[0022] The embodiments disclosed herein provide an easy-to-manage, flexible, and highly utilized secure container memory management method, which aims to solve the performance and flexibility contradictions existing in traditional memory management and huge page technology in secure container environments.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0024] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture diagram to which one embodiment of this disclosure can be applied; Figure 2 This is a flowchart of one embodiment of the memory management method for a secure container according to the present disclosure; Figure 3 This is a schematic diagram of an application scenario of the memory management method for a secure container according to this disclosure; Figure 4 This is a flowchart of yet another embodiment of the memory management method for a secure container according to the present disclosure; Figure 5 This is a schematic diagram of a structure of an embodiment of a memory management device for a secure container according to the present disclosure; Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing embodiments of the present disclosure. Detailed Implementation

[0025] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0026] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the memory management method or apparatus for secure containers of this disclosure can be applied.

[0028] like Figure 1 As shown, system architecture 100 may include servers, host nodes, remote data sources, and databases. A network is used as the medium to provide communication links between the servers, host nodes, data sources, and databases. The network may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0029] The system architecture is a general cloud computing architecture, which can use Kubernetes. The servers provide services such as task initiation, scheduling, and database management.

[0030] A secure container is a container runtime based on lightweight virtual machine or kernel-level emulation technology. By establishing an isolation layer between the container and the host machine, it effectively prevents malicious attacks or the spread of vulnerabilities.

[0031] Each secure container is isolated from the others, has its own file system, and processes within secure containers do not interfere with each other, allowing for the differentiation of computing resources. Compared to virtual machines, secure containers can be deployed quickly. Because secure containers are decoupled from the underlying infrastructure and machine file system, they can be migrated between different clouds and different versions of operating systems.

[0032] Databases are used to store data needed for server scheduling and management, such as cache information and mapping tables of data sources.

[0033] The host node may include a processor and memory. The processor may be a chip with signal processing capabilities. The steps of the method in the embodiments of this application can be implemented through integrated logic circuits in the processor or through software instructions.

[0034] It should be noted that the memory management method of the secure container provided in the embodiments of this disclosure is generally executed by the host node, and correspondingly, the memory management device of the secure container is generally located in the host node.

[0035] It should be understood that Figure 1 The number of servers, host nodes, remote data sources, and databases shown is merely illustrative. Depending on implementation needs, there can be any number of servers, host nodes, remote data sources, and databases. The number of security containers on the host nodes is also illustrative.

[0036] Continue to refer to Figure 2 The diagram illustrates a flow 200 of an embodiment of a memory management method for a secure container according to the present disclosure. The memory management method for the secure container includes the following steps: Step 201: Create a mount point for the virtual file system according to the preset mount parameters.

[0037] In this embodiment, the execution body of the memory management method of the secure container (e.g.) Figure 1 The host node shown can obtain the configuration file from the server via a wired or wireless connection. The configuration file may include information such as mount parameters. The mount parameters may include an identifier indicating whether to enable massive page memory. Mass page size information may also be included in the mount parameters.

[0038] The virtual file system can be tmpfs (a memory-based virtual file system). Using tmpfs as the memory backend, the mount parameter "huge=always" forces the memory region to preferentially use large pages. For example, the command to mount a memory-based temporary file system on the / dev / kata path for Kata Containers runtime is: mount -t tmpfs – o size=100% -o huge=always tmpfs / dev / kata The specific parameters have the following meanings: -t tmpfs The specified file system type to mount is tmpfs. tmpfs is a memory-based temporary file system where data is primarily stored in RAM (and may use swap in some cases). It is characterized by extremely fast read and write speeds, but data is lost after a reboot, making it suitable for storing temporary data.

[0039] -o size=100%

[0040] The mount option for the file system is specified by -o. size=100% means that the maximum size of tmpfs is limited to 100% of the available system memory (the default size of tmpfs is half of the physical memory).

[0041] -o huge=always

[0042] Force tmpfs to use huge pages to allocate memory. A huge page is a larger block of memory than a regular memory page (usually 4KB) (such as 2MB or 1GB), which reduces the CPU's overhead in maintaining page tables and improves the performance of memory-intensive applications (especially suitable for virtualization / container scenarios).

[0043] tmpfs

[0044] This indicates the mounted "device" (logically). tmpfs is a virtual file system with no actual physical device, hence the use of tmpfs as its identifier.

[0045] / dev / kata

[0046] Mount point directory. / dev is typically used to store device files. Kata is associated with Kata Containers (a secure container technology that combines the convenience of containers with the isolation of virtual machines). This directory is a temporary storage path used by Kata at runtime.

[0047] Step 202: Create a secure container and set the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator.

[0048] In this embodiment, secure containers refer to container technologies with strong isolation (such as Kata Containers, Firecracker, etc.). Unlike ordinary containers (such as Docker) which share a host kernel, secure containers are usually implemented based on lightweight virtual machines, with independent kernels and hardware-level isolation, and their security is closer to that of virtual machines.

[0049] Virtual machine emulators are tools that simulate hardware environments (such as QEMU, Cloud Hypervisor, etc.) and serve as the underlying support for secure containers. Secure containers do not run directly on the host kernel, but rather create an isolated virtual machine environment through a virtual machine emulator. The container process actually runs within this lightweight virtual machine, thereby achieving strong isolation.

[0050] A virtual file system is a file system that does not rely on a physical disk and is implemented based on memory or a virtual layer (such as tmpfs, ramfs, etc.). Its characteristics are that data is stored in memory (rather than on disk), the read and write speed is extremely fast, and the life cycle is consistent with that of the container / virtual machine (data is lost after restart).

[0051] The memory backend carrier refers to the fact that the actual storage location of the virtual file system is "memory". That is, the data of the virtual file system is not written to the disk, but is stored and managed in memory as the "carrier".

[0052] When creating a secure container, an isolated, lightweight virtual machine environment is built using a virtual machine emulator (such as QEMU) (this is the core source of the secure container's "security"); at the same time, the file system configured for this secure container is not a traditional disk file system, but a virtual file system (such as tmpfs), and the storage backend of this virtual file system is set to "memory" (i.e., all data runs in memory).

[0053] By using a lightweight virtual machine environment provided by a virtual machine emulator, secure containers can have a kernel and resource space independent of the host, avoiding the security risks (such as the exploitation of kernel vulnerabilities) caused by ordinary containers sharing the host kernel.

[0054] Virtual file systems use memory as their backend, and compared to disk file systems, their read and write speeds are several orders of magnitude faster. They are suitable for fast access to temporary data in containers (such as cache and temporary process files) and reduce I / O bottlenecks.

[0055] The memory-level virtual file system exists throughout the container's lifecycle, and the data is automatically cleared after the container is destroyed, eliminating the need for additional disk cleanup. This aligns with the container's "one-time, stateless" design philosophy.

[0056] Step 203: Use a virtual machine emulator to detect mount parameters to determine whether to enable large page memory.

[0057] In this embodiment, when the secure container starts, the virtual machine emulator needs to manage the container's memory resources. The file system used in the container (such as the previously mentioned tmpfs) may specify a requirement for large page memory through mount parameters (e.g., huge=always). At this time, the virtual machine emulator will actively detect these mount parameters, determine whether the user / configuration requires the use of large page memory, and then decide whether to enable large page memory in the current virtual machine environment.

[0058] Enabling huge page memory requires underlying support (such as pre-allocating huge pages by the system or allowing its use by the virtual machine emulator); simply specifying `huge=always` in the mount parameters is insufficient. The virtual machine emulator can detect these parameters and proactively match the corresponding huge page configuration (e.g., allocating preset huge page memory to the container) to avoid invalid parameters.

[0059] While large pages can improve performance, they consume contiguous physical memory and are unsuitable for fragmented scenarios. If the mount parameters do not require large pages (e.g., huge=never), the emulator can choose not to enable them to avoid wasting large page resources.

[0060] Secure containers rely on virtual machine emulators to achieve strong isolation, and the allocation of memory resources must be uniformly managed by the emulator. By detecting mount parameters, the emulator can ensure that the use of large page memory conforms to the isolation boundaries of the container, avoiding resource conflicts across containers.

[0061] Step 204: In response to determining that large page memory is enabled, request the allocation of large page memory.

[0062] In this embodiment, by detecting mount parameters in the virtual machine emulator (such as detecting parameters like huge=always), the conclusion that "mass page memory needs to be enabled" is finally confirmed (i.e., "enabled is confirmed"). The system (usually a virtual machine emulator, such as QEMU) actively requests the allocation of a specified size or number of massive page memory resources from the underlying memory management system (such as the massive page management module of the Linux kernel) for use by the secure container.

[0063] Traditional big-page technology requires static pre-allocation of fixed memory and lacks dynamic adaptation capabilities, while transparent big-page technology, although supporting dynamic merging, has two major drawbacks: a) Only supports global enabling at the host level; isolation configuration for specific containers is not supported. b) The QEMU virtualization layer cannot recognize the underlying big page memory and still builds the guest memory mapping according to the 4KB page table, thus losing the performance advantage of big pages.

[0064] The methods provided in the above embodiments of this disclosure offer an easy-to-manage, flexible, and highly utilized secure container memory management method. This aims to resolve the performance-flexibility conflict inherent in traditional memory management and huge-page technologies within secure container environments.

[0065] This solution achieves fine-grained transparent huge page management by modifying the QEMU file memory backend. It uses the tmpfs file system as the memory backend carrier and forces the memory region to prioritize huge pages by using the mount parameter "huge=always," thus implementing container-level huge page policy isolation. This allows specific containers to still use huge pages even when the host machine's transparent huge page is globally disabled. Simultaneously, the QEMU memory management module is enhanced to automatically identify the underlying physical memory's huge page size and construct the client page table structure according to the actual huge page specifications when the memory backend file configuration "huge=always" is detected, maintaining compatibility support for 4KB small pages.

[0066] In some optional implementations of this embodiment, requesting the allocation of large page memory includes: calculating the number of large pages based on the total memory and the large page size; and requesting the allocation of contiguous memory blocks based on the large page size and the number of large pages.

[0067] The large page size can be preset in the mount parameters. The required number of large pages is first calculated based on the target memory size and the large page size, and then contiguous physical memory blocks are allocated according to this request. This approach sacrifices memory flexibility (requiring contiguous space) for performance gains, making it particularly suitable for virtualization and memory-intensive scenarios (such as secure containers).

[0068] In some optional implementations of this embodiment, requesting the allocation of large page memory further includes: determining the large page size based on large page configuration information and hardware support capabilities.

[0069] If the large page size is not preset in the mount parameters, it can be inferred through other methods. Alternatively, even if a large page size (e.g., 1GB) is specified in the mount parameters, the configuration will be ineffective if the hardware itself does not support that size (e.g., older CPUs only support 2MB). A larger large page size (e.g., 1GB) results in fewer page table entries and a higher TLB hit rate, but requires more contiguous physical memory space, which can easily lead to allocation failures. Therefore, a compromise must be made based on hardware capabilities and actual needs.

[0070] The system verifies the user-configured bigpage size against the actual hardware capabilities and selects the most suitable bigpage size for allocation. This process ensures that the bigpage configuration meets user needs without exceeding hardware capabilities, making it a key optimization step in high-performance computing and secure container scenarios.

[0071] In some optional implementations of this embodiment, the method further includes: constructing a page table structure for the client; loading the page table structure into the client's virtual address space, enabling the client to access contiguous memory blocks through the page table structure.

[0072] Guest programs use virtual addresses, but the actual data is stored in physical memory. The role of page tables is to establish a mapping between these two. Through page tables, guests can transparently access physical memory without needing to know the location of the actual physical addresses. This process is fundamental to achieving virtual machine / container memory isolation and performance optimization, especially in scenarios with large page memory, where reducing the number of page table entries significantly improves memory access efficiency.

[0073] QEMU obtains file system mount parameters, and its page table build optimizer adopts a 2MB bigpage aligned memory allocation strategy when bigpage mode is activated, reducing mapping levels when building the client EPT page table. QEMU dynamically selects to build client page tables with bigpage sizes by automatically detecting the mount parameters of the memory backend file. Combining the flexibility of tmpfs with the dynamism of transparent bigpages, a hybrid management architecture of file backend + bigpage awareness is formed.

[0074] In some optional implementations of this embodiment, the method further includes: identifying unoccupied fragmented memory pages; and merging the fragmented memory pages into large page memory in response to detecting that the total capacity of the fragmented memory pages has reached a preset size.

[0075] Small, non-contiguous memory blocks in physical memory (typically 4KB ordinary pages) become fragmented due to frequent allocation and deallocation, failing to meet the contiguous space requirements of large pages. The operating system uses the memory management unit or page table information to mark which physical page frames are currently unused (i.e., free pages). It then identifies contiguous small page blocks from these free pages, for example: page frames 100-103 (four consecutive 4KB pages, totaling 16KB); page frames 200-207 (eight consecutive 4KB pages, totaling 32KB).

[0076] The system accumulates the total capacity of all consecutive small page blocks. When the total capacity of the scattered pages is greater than or equal to a preset size (e.g., 16MB), the system initiates the merging process. If there is active data in the scattered pages, it must first be migrated to other memory areas to ensure that the page frames are completely free. Consecutive small page frame groups (e.g., 512 4KB pages) are merged into one large page (e.g., 2MB), and the page table is updated. The merged large page is added to the system's large page memory pool for subsequent allocation (e.g., via the HUGETLBFS file system).

[0077] This dynamic adjustment mechanism balances memory utilization and performance, making it particularly suitable for virtualization scenarios that require large amounts of contiguous memory (such as secure containers).

[0078] In some optional implementations of this embodiment, the method further includes: detecting the memory access pattern of the client workload; and dynamically adjusting the large page size used according to the memory access pattern.

[0079] Memory access patterns refer to the characteristics of how client programs access memory, such as: Sequential access: reading large blocks of data sequentially (e.g., database scans); Random access: frequently jumping between different addresses (e.g., cache misses); Memory-intensive: frequent reading and writing of large amounts of data in memory.

[0080] Based on the real-time access pattern, the system automatically selects the most suitable large page size (such as 2MB or 1GB) instead of using a fixed single size.

[0081] Different workloads have significantly different requirements for large page sizes. Large pages (e.g., 1GB) are suitable for sequential access or memory-intensive workloads (such as databases and machine learning), which can significantly reduce page table entries and TLB failures. Small pages (e.g., 2MB) are suitable for random access or scenarios with severe memory fragmentation, offering greater flexibility and avoiding allocation failures due to insufficient contiguous space.

[0082] If a fixed 1GB large page is used, memory fragmentation will cause large page allocation failure when the workload involves frequent random access; if a fixed 2MB large page is used, the performance advantage cannot be fully utilized for sequential access workloads.

[0083] The system can analyze the client's memory access behavior in the following ways: 1. Hardware assistance: CPU performance counters (such as Intel PMU) record TLB misses, cache hit rates, and other metrics.

[0084] Page table traversal statistics: Monitor the access frequency of page table entries of different sizes.

[0085] 2. Software Analysis: Tracing memory access addresses: calculating address contiguity and spatial locality.

[0086] Workload Classification: Identify typical patterns such as databases, web servers, and scientific computing.

[0087] 3. Machine learning models: The model is trained based on historical data to predict workload types and optimal big page configurations.

[0088] The system analyzes client memory usage characteristics through collaborative hardware and software analysis. Based on the pattern analysis results, it automatically selects the optimal large page size, balancing performance and resource utilization. This adaptive mechanism enables the system to maintain efficient memory access under different workloads, making it particularly suitable for cloud environments and secure container scenarios with hybrid deployments of multiple applications.

[0089] See also Figure 3 , Figure 3This is a schematic diagram illustrating an application scenario of the memory management method for secure containers according to this embodiment. It describes the core logic of how the QEMU virtualization layer optimizes memory management through Huge Page technology when allocating memory for secure containers. Combining the memory isolation and performance requirements of secure containers, the specific process is as follows: 1. QEMU Initialize Memory Backend Prepare the basic environment for physical memory mapping for client machines / secure containers.

[0090] 2. Check if the startup parameter mem-path contains the huge option.

[0091] Decide whether to enable large page mode

[0092] 2.1 Huge mode (huge=always)

[0093] Memory allocation: Memory is allocated in 2MB alignment (typical granularity of large pages, but 1GB can also be supported; the core is "larger page size").

[0094] Page table construction: EPT page tables (Extended Page Tables in Intel Virtualization technology, used for secondary mapping from host to guest physical memory) are built for the guest machine. In big-page mode, EPT also uses big pages to reduce the number of page table levels (for example, a 4KB page may require 3-4 levels of page tables, while a 2MB big page may only require 2 levels).

[0095] EPT is key to isolating guest memory in the virtualization layer: the host controls guest access to physical memory through EPT. In big-page mode, the EPT structure is simpler, the mapping of host to guest memory is more efficient, and the isolation rules are easier to maintain (reducing the attack surface for page table tampering and out-of-bounds access).

[0096] 2.2 Traditional 4KB mode (without huge parameter)

[0097] Memory allocation: Based on standard 4KB page allocation (traditional memory page granularity, with many page table entries and deep hierarchy).

[0098] This solution offers three major advantages: flexible memory management, performance enhancement, and secure isolation. It retains the dynamic merging characteristics of transparent huge pages and supports runtime huge page splitting and reclamation, while reducing TLB miss rates and guest memory access latency. Simultaneously, it avoids security policy conflicts caused by enabling global THP (Transparent Huge Pages) and supports fine-grained memory controller management. Through the collaborative design of the file system layer and virtualization layer, it achieves refined application of transparent huge page technology in secure container environments, maintaining the advantages of dynamic memory management while achieving performance gains close to those of static huge pages.

[0099] Further reference Figure 4 This illustrates a flow 400 of another embodiment of a memory management method for a secure container. Flow 400 of this memory management method for a secure container includes the following steps: Step 401: Create a mount point for the virtual file system according to the preset mount parameters.

[0100] Step 402: Create a secure container and set the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator.

[0101] Step 403: Use a virtual machine emulator to detect mount parameters to determine whether to enable large page memory.

[0102] Step 404: In response to determining that large page memory is enabled, request the allocation of large page memory.

[0103] Steps 401-404 are basically the same as steps 201-204, so they will not be described again.

[0104] Step 405: Monitor at least one of the following memory performance metrics: memory access latency, TLB hit rate, memory fragmentation rate, and memory bandwidth utilization.

[0105] In this embodiment, the meaning of each performance indicator is as follows: Memory access latency refers to the time interval (usually measured in nanoseconds, such as ~30ns for typical DDR5) between when the CPU initiates a memory read / write request and when the data is actually retrieved. Higher latency means a longer wait time for a program to respond to memory, directly impacting overall performance (e.g., database queries and real-time computing are latency-sensitive).

[0106] A high TLB hit rate results in fewer lookups in slow page tables, leading to faster memory access (e.g., big-page techniques increase page size, expanding TLB coverage and indirectly improving the hit rate). A low TLB hit rate causes frequent traversals of multi-level page tables, resulting in additional latency (and potentially triggering page faults, slowing down the program).

[0107] Memory fragmentation rate refers to the proportion of free memory that cannot be allocated contiguously to the total free memory. A high fragmentation rate leads to decreased memory utilization and may even cause allocation failures (such as when a container requests a large page but cannot satisfy the request due to fragmentation). It can also indirectly reduce the TLB hit rate (by forcing the use of small pages).

[0108] Memory bandwidth utilization refers to the actual amount of data read and written into memory divided by the theoretical maximum memory bandwidth, multiplied by 100%. High utilization indicates busy memory, which may become a performance bottleneck (e.g., during multi-threaded parallel computing, full bandwidth can cause threads to wait); low utilization indicates idle memory resources, requiring optimization of program memory access patterns (e.g., reducing invalid reads and writes).

[0109] Memory performance monitoring needs to focus on core dimensions, covering at least one key metric, in order to effectively identify memory bottlenecks, optimize performance, or ensure stability. Different scenarios (such as high-performance computing, virtualization, and containers) can select key metrics to monitor based on their needs.

[0110] Step 406: Adjust the flags according to performance metrics and reclaim unused large page memory.

[0111] In this embodiment, the strategy for dynamically adjusting the identifier based on the monitored performance indicators is as follows: 1. Low TLB hit rate ① If the large pages are not aligned, a stricter large page alignment will be forced (e.g., change from 2MB alignment to 1GB alignment, and expand the TLB coverage). ② If there are not enough large pages, adjust the flag to "prioritize large page allocation" and supplement large page resources.

[0112] 2. High memory fragmentation rate

[0113] ① If there are many large page fragments, adjust the flag to "Allow temporary rollback to small pages" (to reduce the blocking of allocation by large page fragments); ② Limit the over-allocation of large pages to avoid fragmentation accumulation.

[0114] 3. High memory access latency

[0115] If large page allocation fails (forcing the use of small pages and increasing page table traversal), the flag will be changed to "force large page allocation" to prioritize latency-sensitive scenarios.

[0116] 4. Low memory bandwidth utilization

[0117] If large pages are not fully utilized (e.g., there is a lot of free space within a large page), the flag will be adjusted to "split large pages into smaller pages" (to improve bandwidth utilization and reduce ineffective idle space).

[0118] The reason for reclaiming unused large pages is that large pages (such as 2MB / 1GB) are difficult to dynamically reclaim after allocation. Large pages require contiguous physical memory, and if left idle for a long time, they will occupy valuable contiguous memory areas, causing new large page allocation to fail (external fragmentation). In secure container scenarios, large pages that are not reclaimed in time after a container shrinks or is destroyed will waste resources and may even cause "large page starvation" (no resources are available when other containers request large pages).

[0119] The steps for reclaiming unused large page memory may include: 1. Identify idle large pages: Mark large pages that are not mapped by the client or have been released by the container but not returned, through memory mapping tables (such as QEMU's memory backend or container memory statistics); 2. Safe reclamation: Ensure that large pages are not used by active processes (to avoid corrupting running memory data) and return them to the system large page pool (such as the large page resources managed by / dev / hugepages in Linux) for subsequent reallocation.

[0120] The load on the secure container may fluctuate (such as business peaks / off-peaks). During peaks, high performance (high TLB hit rate, low latency) is ensured by increasing the priority of large page allocation (adjusting the flag) and reclaiming idle large pages. During off-peaks, large pages are reclaimed and a small page strategy is switched to improve memory utilization (reduce fragmentation caused by idle large pages).

[0121] Reclaiming large pages prevents "zombie large pages" from being maliciously exploited (e.g., container escape attacks may attempt to hijack the memory mapping of idle large pages); adjusting the flag can dynamically tighten / relax the large page policy (e.g., forcing large page alignment during an attack, increasing the difficulty of the attack).

[0122] By monitoring feedback, the big page strategy is dynamically adjusted and idle resources are reclaimed, ultimately achieving a balance between "high performance, high utilization, and high security" in secure container memory.

[0123] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a memory management device for a secure container, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0124] like Figure 5 As shown, the memory management device 500 for a secure container in this embodiment includes: a mounting unit 501, a creation unit 502, a detection unit 503, and an allocation unit 504. The mounting unit 501 is configured to create a mount point for a virtual file system according to preset mounting parameters, wherein the mounting parameters include an identifier indicating whether massive page memory is enabled. The creation unit 502 is configured to create a secure container and set the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator. The detection unit 503 is configured to detect the mounting parameters through the virtual machine emulator to determine whether massive page memory is enabled. The allocation unit 504 is configured to request the allocation of massive page memory in response to determining that massive page memory is enabled.

[0125] In this embodiment, the specific processing of the mounting unit 501, creation unit 502, detection unit 503, and allocation unit 504 of the memory management device 500 of the secure container can be referred to Figure 2 The corresponding steps are 201, 202, 203 and 204 in the embodiment.

[0126] In some optional implementations of this embodiment, the allocation unit 504 is further configured to: calculate the number of large pages based on the total memory and the large page size; and request the allocation of contiguous memory blocks according to the large page size and the number of large pages.

[0127] In some optional implementations of this embodiment, the allocation unit 504 is further configured to determine the large page size based on large page configuration information and hardware support capabilities.

[0128] In some optional implementations of this embodiment, the apparatus further includes a page table building unit (not shown in the figures), configured to: build a page table structure for the client; load the page table structure into the client's virtual address space, enabling the client to access contiguous memory blocks through the page table structure.

[0129] In some optional implementations of this embodiment, the device further includes a merging unit (not shown in the figures), configured to: identify unoccupied fragmented memory pages; and merge the fragmented memory pages into large page memory in response to detecting that the total capacity of the fragmented memory pages has reached a preset size.

[0130] In some optional implementations of this embodiment, the device further includes a monitoring unit (not shown in the figures), configured to: monitor at least one of the following performance metrics of the memory: memory access latency, TLB hit rate, memory fragmentation rate, and memory bandwidth utilization; adjust the flags according to the performance metrics; and reclaim unused large page memory.

[0131] In some optional implementations of this embodiment, the device further includes a detection unit (not shown in the figures) configured to: detect the memory access pattern of the client workload; and dynamically adjust the large page size used according to the memory access pattern.

[0132] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0133] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0134] An electronic device includes: one or more processors; and a storage device having one or more computer programs stored thereon, which, when executed by the one or more processors, cause the one or more processors to implement the method described in process 200 or 400.

[0135] A computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in process 200 or 400.

[0136] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0137] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0138] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0139] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as road planning methods. For example, in some embodiments, the road planning method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the road planning method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the road planning method by any other suitable means (e.g., by means of firmware).

[0140] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0141] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0142] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0143] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0144] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0145] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be servers in distributed systems or servers incorporating blockchain technology. Servers can also be cloud servers, or intelligent cloud computing servers or intelligent cloud hosts with artificial intelligence technology.

[0146] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0147] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A memory management method for a secure container, comprising: A mount point for a virtual file system is created based on preset mount parameters, wherein the mount parameters include an identifier indicating whether large page memory is enabled. Create a secure container and set the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator; The mount parameters are detected by the virtual machine emulator to determine whether to enable large page memory. In response to the determination that large page memory is enabled, a request is made to allocate large page memory.

2. The method according to claim 1, wherein, The request to allocate large page memory includes: Calculate the number of big pages based on the total memory and the big page size; Request allocation of contiguous memory blocks according to the stated page size and the stated number of pages.

3. The method according to claim 2, wherein, The request to allocate large page memory also includes: The size of the large page is determined based on the large page configuration information and hardware support capabilities.

4. The method according to claim 2 or 3, wherein, The method further includes: Construct the client's page table structure; The page table structure is loaded into the virtual address space of the client, enabling the client to access the contiguous memory block through the page table structure.

5. The method according to claim 1, wherein, The method further includes: Identify unoccupied, fragmented memory pages; In response to the detection that the total capacity of the scattered memory pages has reached a preset size, the scattered memory pages are merged into a large page memory.

6. The method according to claim 1, wherein, The method further includes: Monitor at least one of the following memory performance metrics: memory access latency, TLB hit rate, memory fragmentation rate, and memory bandwidth utilization. Adjust the flag based on the performance metrics and reclaim unused large page memory.

7. The method according to claim 1, wherein, The method further includes: Detect the memory access patterns of the client workload; The size of the large page used is dynamically adjusted according to the memory access mode.

8. A memory management device for a secure container, comprising: The mounting unit is configured to create a mount point for a virtual file system according to preset mounting parameters, wherein the mounting parameters include an identifier for indicating whether large page memory is enabled. The creation unit is configured to create a secure container and set the virtual file system as the memory backend carrier of the secure container through a virtual machine emulator; The detection unit is configured to detect the mount parameters through the virtual machine emulator to determine whether to enable large page memory; The allocation unit is configured to request the allocation of large page memory in response to the determination that large page memory is enabled.

9. An electronic device, comprising: One or more processors; Storage device, on which one or more computer programs are stored, When the one or more computer programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images