Processing method and device of shared memory, computer device and storage medium

Abstract

The present disclosure provides a shared memory processing method and device, computer equipment and storage medium, the method comprises: in response to the application request of the shared memory space of the first process, allocating the shared memory space for the first process, and creating the exclusive metadata for managing the shared memory space and the process metadata for recording the process information of the first process; wherein the process metadata corresponding to the first process is associated with the exclusive metadata, and the process information of the first process is not written into the exclusive metadata; in response to the sharing request of the second process to the shared memory space, creating the process metadata for recording the process information of the second process, and associating the process metadata of the second process to the exclusive metadata.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to methods, apparatus, computer devices and storage media for processing shared memory. Background Technology

[0002] In the reserved memory scenario, a portion of physical memory is allocated to the reserved memory management module for use by specific processes. Currently, each time the reserved memory management module allocates memory space to a process, it creates a dedicated metadata mmap. This dedicated metadata is a special structure that manages the memory information allocated to the process, recording the physical address range and process information, such as the process identifier and virtual address range. All dedicated metadata mmaps are placed in a linked list that maintains mmaps. Each mmap is uniquely identified by a physical address and corresponds one-to-one with the process identifier (PID).

[0003] The reserved memory management module currently does not implement shared memory functionality. Shared memory refers to a memory space that can be used by multiple processes. To implement shared memory, the shared memory space would correspond to multiple processes, meaning a single physical address would correspond to information from different processes. Creating mmap for each process would disrupt the original uniqueness logic. If mmap is only created for one process, it becomes difficult to manage the process information of other shared processes. Therefore, how to implement shared memory in a reserved memory scenario is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] To overcome the problems existing in the related technologies, this disclosure provides a method, apparatus, computer equipment and storage medium for processing shared memory.

[0005] According to a first aspect of the embodiments of this specification, a method for processing shared memory is provided, the method comprising:

[0006] In response to the shared memory space request of the first process, a shared memory space is allocated to the first process, and proprietary metadata for managing the shared memory space and process metadata for recording the process information of the first process are created; wherein, the process metadata corresponding to the first process is associated with the proprietary metadata, and the process information of the first process is not written into the proprietary metadata.

[0007] In response to the second process's request to share the shared memory space, process metadata that records the process information of the second process is created, and the process metadata of the second process is associated with the proprietary metadata.

[0008] According to a second aspect of the embodiments of this specification, a shared memory processing apparatus is provided, comprising:

[0009] The application processing module is used to respond to the application request for shared memory space of the first process, allocate shared memory space for the first process, and create proprietary metadata for managing the shared memory space and process metadata for recording the process information of the first process; wherein, the process metadata corresponding to the first process is associated with the proprietary metadata, and the process information of the first process is not written into the proprietary metadata.

[0010] The shared processing module is used to respond to the second process's request to share the shared memory space, create process metadata that records the process information of the second process, and associate the process metadata of the second process with the proprietary metadata.

[0011] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method embodiments described in the first aspect above.

[0012] According to a fourth aspect of the embodiments of this specification, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method embodiments described in the first aspect above.

[0013] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0014] In the embodiments described in this specification, the first process to request shared memory space will still establish its own proprietary metadata mmap. However, this proprietary metadata is not written into the process information, so it does not correspond to a specific process. For this first process and subsequent processes sharing the memory space, process metadata recording process information will be established, and each process's process metadata will be associated with the proprietary metadata. Based on this, the proprietary metadata mmap will not correspond to multiple processes, thus not violating the original uniqueness logic. Furthermore, since the process metadata of each process is associated with the same proprietary metadata mmap, the process metadata of each process can be managed through the proprietary metadata mmap.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this specification and, together with the specification, serve to explain the principles of this disclosure.

[0017] Figure 1AThis is a schematic diagram illustrating a reserved memory scenario according to an exemplary embodiment of this specification.

[0018] Figure 1B This is a schematic diagram illustrating a shared memory scenario according to an exemplary embodiment of this specification.

[0019] Figure 2A This is a flowchart illustrating a shared memory processing method according to an exemplary embodiment of this specification.

[0020] Figure 2B This is a schematic diagram illustrating a NUMA architecture according to an exemplary embodiment of this specification.

[0021] Figures 2C to 2F These are schematic diagrams illustrating proprietary metadata and process metadata according to an exemplary embodiment of this specification.

[0022] Figure 3 This is a hardware structure diagram of a computer device containing a shared memory processing apparatus, as illustrated in this specification according to an exemplary embodiment.

[0023] Figure 4 This is a block diagram illustrating a shared memory processing apparatus according to an exemplary embodiment of this specification. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0025] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] Computer devices can employ a traditional memory management architecture, where a single memory management module within the operating system manages the entire memory. Currently, common operating system memory management modules divide physical memory into 4KB (kilobyte) memory pages, using the page as the basic unit for physical memory allocation and deallocation. In other scenarios, such as virtual machines (VMs), computer devices can use a memory management architecture with reserved memory, such as... Figure 1A The diagram shown is a schematic representation of a reserved memory scenario illustrated in this specification. In this architecture, the host machine's memory can be divided into multiple memory spaces, such as... Figure 1A The diagram illustrates two memory spaces using different padding methods: a non-reserved memory space for the kernel (filled with diagonal lines), and a reserved memory space for virtual machines (filled with grid lines). Specifically, non-reserved memory space a is used by the kernel, and applications running on the operating system (applications 1 to 3 in the example) can use this space. Reserved memory space b, on the other hand, is used by virtual machines, such as VM1 to VMn (a total of n virtual machines). These two memory spaces can employ different management granularities; that is, the granularity of memory allocation can be different. Figure 1A For ease of illustration, the two memory spaces are shown as contiguous in the diagram. However, in real-world applications, these two memory spaces can be non-contiguous. Furthermore, in practical applications, even more memory spaces can be partitioned.

[0028] Reserved memory space occupies a large portion of memory and is unavailable to the host kernel. A module can be inserted into the operating system kernel specifically for managing the reserved memory space. To facilitate the management of this series of memory spaces while avoiding the memory consumption of a large amount of metadata, and considering that the memory allocated to virtual machines is often at least several hundred MB (MByte), the reserved memory space is divided with a larger granularity, such as dividing the reserved memory space into memory sections (MS) of 2MB each for management. In some scenarios, large granularity is also commonly used, such as 1GB (Gigabyte), which is optional. This embodiment does not limit this.

[0029] When applied to reserved memory scenarios, the operating system can use different modules to manage reserved memory space and non-reserved memory space respectively. For example, the operating system's reserved memory management module manages the reserved memory space, while the kernel's memory management module manages the non-reserved memory space.

[0030] In reserved memory scenarios, when user-space applications need to allocate memory, they request it through the reserved memory allocation interface. The reserved memory management module then allocates a segment of the required memory from unallocated memory for the application to use. Currently, the reserved memory scenario does not provide the functionality for multiple applications to share the same reserved memory.

[0031] like Figure 1B The diagram illustrates a shared memory scenario according to an exemplary embodiment of this specification. A block of physical memory can be mapped to multiple processes with usage permissions. These permissions can be used by the processes. Usage permissions may include read-only, write-only, or read / write permissions. Various information needs to be recorded for managing the shared memory space, such as: the identifier of the allowed process, the physical starting address of the shared memory space, the size of the shared memory space, the logical starting address of the shared memory space used by each process, and the usage permissions of each process.

[0032] Implementing shared memory in a reserved memory scenario presents several challenges. Each time the reserved memory management module allocates memory space to the virtual machine, it creates corresponding metadata, referred to in this embodiment as a dedicated metadata mmap (memorymap, a mapping between virtual and physical memory addresses; here, mmap refers to this dedicated metadata). This dedicated metadata is a special structure that manages the memory information allocated to the virtual machine. The mmap structure records the allocated physical memory range, the corresponding virtual address, the process ID (PID), and other allocation information. All mmap structures are stored in a data structure (e.g., a linked list) that maintains the mmap. The unique identifier of each mmap structure is its physical address. Without shared memory, each mmap corresponds one-to-one with a process ID.

[0033] Because the reserved memory management module manages the allocation and release of reserved memory based on physical memory, the physical address (paddr) of the physical memory contained in each allocated mmap structure is unique and there are no overlaps. Its related sub-functions (such as hot and cold memory, memory swapping, and memory fault handling) use this unique information to reverse-engineer the corresponding process ID (PID) and the virtual address (vaddr) within the process, thereby performing the appropriate page table read / write operations based on the virtual address (vaddr).

[0034] In a shared memory scenario, a range of physical addresses is shared among multiple processes. If each process sharing memory were to create its own mmap, it would mean that one physical address paddr corresponds to multiple different process pids, and there would also be multiple different virtual addresses vaddr for each process. Creating an mmap for each process would break the original uniqueness logic and damage the functionality of the existing memory management module.

[0035] Furthermore, if only one process A has its corresponding mmap created, while other processes are associated with this mmap through other data structures instead of creating mmaps themselves, other problems arise. For example, when processes releasing shared memory, it's impossible to guarantee which process releases first. If process A doesn't release first, it's relatively easy to handle. However, if process A releases first, its corresponding mmap will also be released, and the memory mapping information of other unreleased shared processes will be lost. If this mmap isn't released, it needs to be unassociated with process A and then associated with another process B, and then the remaining processes need to establish new associations with process B. During this process, if the shared mapped memory region changes, it involves updating the shared mmap information and releasing some unshared information, making the management logic extremely complex.

[0036] Therefore, in order to handle new shared memory scenarios simply without disrupting the original uniqueness logic of the reserved memory management mmap information, this embodiment provides a shared memory processing scheme. In this embodiment, the first process to request shared memory space will still create a dedicated metadata mmap, but this dedicated metadata is not written into the process information, so that the dedicated metadata does not correspond to a process. For this first process and other processes that subsequently share the memory space, process metadata recording process information will be created, and the process metadata of each process will be associated with the dedicated metadata. Based on this, the dedicated metadata mmap will not correspond to multiple processes, will not disrupt the original uniqueness logic, and the process metadata of each process will be associated with the same dedicated metadata mmap, so that the process metadata of each process can be managed through the dedicated metadata mmap. The embodiments of this specification will be described in detail below.

[0037] like Figure 2A As shown, Figure 2A This is a flowchart illustrating a shared memory processing method according to an exemplary embodiment, comprising the following steps:

[0038] In step 202, in response to the request for shared memory space from the first process, shared memory space is allocated to the first process, and proprietary metadata for managing the shared memory space and process metadata for recording the process information of the first process are created.

[0039] The process metadata corresponding to the first process is associated with the proprietary metadata, and the process information of the first process is not written into the proprietary metadata.

[0040] In step 204, in response to the second process's request to share the shared memory space, process metadata that records the process information of the second process is created, and the process metadata of the second process is associated with the proprietary metadata.

[0041] The solution in this embodiment can be applied to any computer device. The computer device can be a single-core CPU device or a device including multiple physical CPUs (Central Processing Units). Depending on the needs, a Non-Uniform Memory Access Architecture (NUMA) can be adopted. A NUMA architecture includes at least two NUMA nodes, such as... Figure 2B As shown, using two NUMA nodes as an example, the host machine can include NUMA node 1 and NUMA node 2. In a NUMA architecture, multiple physical CPUs and multiple memory modules of the host machine belong to different NUMA nodes. Each NUMA node includes at least one physical CPU and at least one physical memory module. Figure 2B Taking a NUMA node consisting of one physical CPU and one physical memory as an example. Within a NUMA node, the physical CPU and physical memory communicate using the Integrated Memory Controller Bus (IMC Bus), while NUMA nodes communicate with each other using Quick Path Interconnect (QPI). Because the latency of QPI is higher than that of the IMC Bus, the physical CPU's access to memory on the host machine differs in terms of distance (remote / local). The physical CPU can access the physical memory of its own node faster, while accessing the physical memory of other NUMA nodes is slower.

[0042] In a NUMA architecture scenario, the memory in this embodiment may include any of the aforementioned physical memory. Optionally, any physical memory in a NUMA architecture may also employ a reserved memory architecture. Therefore, the memory space managed in this embodiment may also refer to the memory space within any physical memory in a NUMA architecture. It is understood that in practical applications, computer devices may also employ other architectures. Depending on actual needs, the memory referred to in this embodiment may have multiple implementation methods depending on the actual application scenario, which will not be listed here.

[0043] The process in this embodiment may include any process running in a computer device, such as the aforementioned virtual machine, etc.

[0044] The method described in this embodiment can be applied to the operating system of any computer device. In the aforementioned reserved memory scenario, it can be applied to the reserved memory management module of the operating system as a sub-function of the reserved memory management module. Alternatively, it can be implemented as an independent module based on the method described in this embodiment and inserted into the operating system.

[0045] In practical applications, for processes to share a segment of physical memory, an operation is needed to map the physical memory to the process's virtual address space. The kernel's shared memory functionality is presented externally in the form of a memory file system. This memory file system can present a segment of memory to a process as a file, allowing the process to directly manipulate the file to initiate the mapping operation to the process's virtual address space. In reserved memory scenarios, to preserve the usage habits of user-mode applications and facilitate their use, this embodiment can also implement shared memory functionality using a memory file system. This memory file system is inserted into the operating system as an independent module. That is, the method in this embodiment can be applied to a memory file system, and user-mode programs using reserved memory space can use the shared memory functionality provided by this memory file system.

[0046] In this embodiment, assuming the first process requests a shared memory space for the first time, the first process can initiate a shared memory space request. This request can carry the size of the shared memory space and information representing the shared memory. After receiving the request, the reserved memory management module can allocate shared memory space for the first process, create a dedicated metadata mmap to manage the shared memory space, and create process metadata share_entry corresponding to the first process. The process metadata share_entry is associated with the dedicated metadata, meaning it is located below the dedicated metadata mmap. The dedicated metadata mmap does not contain the identification information of the first process; that is, it inherits the characteristics of the original mmap but does not correspond to a process. For example, the dedicated metadata mmap records the allocation information, including the physical address range or the corresponding virtual address range, but does not record the process identification information.

[0047] In some examples, the proprietary metadata includes fields that record process identification information; the creation of proprietary metadata for managing the shared memory space includes:

[0048] Write a specified flag into the field of the identification information of the recorded process to prevent the process information of the first process from being written into the proprietary metadata; or,

[0049] The field of the identification information of the recorded process is set to empty so that the process information of the first process is not written into the proprietary metadata.

[0050] In this embodiment, the field for recording the process identifier information in the original proprietary metadata mmap can be left empty, ensuring that the process information of the first process is not written into the proprietary metadata, thus preventing the proprietary metadata from corresponding to any process. Alternatively, a specified flag can be written, which can be flexibly configured as needed. The specified flag indicates that the proprietary metadata does not correspond to any process, for example, it is not the same as the identifier of any process, ensuring that the process information of the first process is not written into the proprietary metadata. This embodiment allows for the quick implementation of ensuring that the process information of the first process is not written into the proprietary metadata during the creation of proprietary metadata.

[0051] Therefore, once the shared memory space is allocated, it can be shared by other processes with the appropriate permissions. Through the above-described metadata design, the complexity of shared memory management logic is significantly reduced. When the first process requests shared memory space, one or more other processes can have the permission to use it; the first process and these other processes can be referred to as sharing processes. For example, taking the second process requesting sharing as an example, the second process can initiate a sharing request for the shared memory space. In some examples, the second process's request for sharing the shared memory space can be for the entire space or only a portion of it. This embodiment does not require creating dedicated metadata mmap; instead, it creates process metadata corresponding to the second process and associates the second process's process metadata with the dedicated metadata. The process for other processes to request sharing is similar. Figure 2C and Figure 2D As shown, Figure 2C This is a schematic diagram of an mmap linked list, showing multiple mmaps in the list, including mmap1, mmap2, and mmap3; for simplicity, other proprietary metadata such as mmap4 after mmap3 are not shown. Each mmap, as a node in the linked list, can be linked via address pointers. Figure 2C The diagram shows the unidirectional linking of each mmap instance with its address pointers, indicated by a single arrow. In practical applications, the mmap linked list can also adopt a doubly linked list structure, but this embodiment does not limit this. Figure 2D The image shows multiple process metadata associated with mmap2 and mmap3. Taking mmap2 as an example, it associates metadata with three processes. Figure 2D The process metadata 21, process metadata 22, and process metadata 23 are included; mmap3 takes as an example the association of two process metadata sets, namely... Figure 2D The process metadata 31 and process metadata 32 are in the data.

[0052] The association between proprietary metadata mmap and process metadata can be implemented in several ways. For example, in proprietary metadata mmap, a free field can be selected to store the head node of a linked list, while other nodes in the linked list store address pointers to the metadata of each process. The address pointers of each node in the linked list can then be used to link to the metadata of each process. If the reserved field for proprietary metadata is large, storing the metadata of each process in the nodes of the linked list is also optional.

[0053] Subsequently, a process can terminate its use of the shared memory space. The process terminating its use can be any of the aforementioned shared processes, i.e., the first process that requested the shared memory space, and any other process that requested to share the shared memory space. For example, taking a third process requesting release as an example, the third process can be the aforementioned first process or any second process. In some examples, the method may further include: in response to the third process's request to release the shared memory space, obtaining the proprietary metadata of the shared memory space, finding the process metadata of the third process from the process metadata associated with the proprietary metadata, and releasing it, i.e., deassociating the process metadata of the third process with the proprietary metadata. It can be understood that the third process is a process with usage rights to the shared memory space, and before requesting release, the third process has already requested to share the shared memory space. Assuming the third process corresponds to process metadata 23, if the third process requests release, the proprietary metadata mmap2 corresponding to the shared memory space is obtained through the mmap linked list, and then process metadata 23 is found from the process metadata associated with the proprietary metadata mmap2 and deleted. After deletion, as... Figure 2E As shown. In this way, when a process requests and releases shared memory space, there is no need to modify the proprietary metadata mmap, and it will not affect the association between other processes participating in the sharing and the proprietary metadata mmap.

[0054] In other examples, the method further includes: if, after releasing the process metadata of the third process, the proprietary metadata of the shared memory space is not associated with the process metadata, releasing the proprietary metadata and reclaiming the shared memory space. For example, as... Figure 2E As shown, the shared memory space corresponding to mmap2 is currently shared by two processes. If the process corresponding to process metadata 22 requests release, after deleting process metadata 22, only one process remains. When this process also requests release, since mmap2 is only associated with one process metadata 21, mmap2 can be released, and the shared memory space can be reclaimed. Subsequent metadata can be handled as follows... Figure 2F As shown in the above embodiments, the release of shared memory space can be achieved relatively quickly.

[0055] The fields in the proprietary metadata include fields for recording virtual address information of the process, process identification information, and physical address information, etc. As mentioned earlier, the proprietary metadata does not contain process identification information, therefore this metadata does not correspond to a process. However, the field for recording the virtual address information of the process needs to contain virtual address information in some scenarios. For example, when an existing reserved memory management module allocates the required memory space to a process, its pass parameters include the virtual address range corresponding to the memory space required by the process. In order to reuse the functionality of the existing reserved memory management module, in some examples, the allocation of shared memory space for the first process and the creation of proprietary metadata for managing the shared memory space include:

[0056] Based on the size information carried in the application request, allocate a kernel-mode virtual address range and allocate shared memory space for the first process;

[0057] Obtain the physical address range of the shared memory space;

[0058] Generate proprietary metadata to manage the shared memory space. The proprietary metadata records physical address information representing the physical address range and virtual address information representing the kernel-mode virtual address range.

[0059] When the first process requests shared memory space, virtual addresses are used to allocate the shared memory space in order to reuse the functionality of the existing reserved memory management module. In this embodiment, the proprietary metadata mmap does not correspond to a process, so the allocated virtual address range adopts the kernel-mode virtual address range, without using the process's virtual address space. After the shared memory space is allocated, the physical address range of the shared memory space is obtained; proprietary metadata for managing the shared memory space is generated. The proprietary metadata records the physical address information representing the physical address range and the virtual address information representing the kernel-mode virtual address range. Therefore, in this embodiment, even though the proprietary metadata mmap does not correspond to a process, the functionality of the existing reserved memory management module can be reused by configuring the kernel-mode virtual address range.

[0060] In this embodiment, the first process to request shared memory space creates process metadata, in addition to creating its own proprietary metadata, also creates process metadata that records its process information. Subsequent processes, such as a second process, also create process metadata that records their process information when requesting to share the shared memory space. The process of creating process metadata is the same. In step 204, the second process can refer to one or more other processes that subsequently request to share the shared memory space. Furthermore, the second process's request to share the shared memory space can specify all or part of the shared memory space.

[0061] There are multiple ways to create process metadata, and the information recorded in the process metadata can be configured as needed. For example, it can include process identification information, the range of memory to be shared (which can include physical address range information and virtual address range information), and so on. As an example, the allocation of the virtual address range for user-mode applications is implemented by the kernel-provided system call `mmap()`. Unlike the aforementioned proprietary metadata `mmap`, here `mmap()` refers to the kernel-provided interface name. This interface is used to map shared memory to user-mode processes. In the kernel, the `mmap()` system call can map the file that a process wants to share to the process's virtual address space. The output of this interface is the virtual address range that the process wants to share. That is, for a process's request to share shared memory space, the `mmap()` interface needs to be called to obtain the process's virtual address range. After the `mmap()` interface is called, it also generates vma metadata, namely the kernel's `vm_area_struct` structure, or simply `vma`, also known as the process address space or process linear region. The kernel uses this structure to define virtual memory regions and is the most basic management unit for virtual memory management. VMA metadata uses virtual addresses as unique identifiers. Therefore, when creating process metadata, the VMA metadata can be obtained through the mmap() system call. Virtual address information, such as the starting virtual address and size, can then be parsed from the VMA metadata. Afterward, process metadata is allocated, recording the virtual address range, physical address range, and process identification information, thus completing the creation of the process metadata.

[0062] A process can initiate a release request when it no longer needs to use the shared memory space. Processes can only use the virtual address space, and the release request carries the virtual address of the shared memory space the process wants to release. Accordingly, it is necessary to find the process metadata corresponding to the shared memory space. As seen in the previous embodiments, the process metadata is mounted under the proprietary metadata mmap, but the proprietary metadata does not correspond to a specific process. Therefore, in some examples, the method may further include:

[0063] Obtain the VMA metadata of the first process, and associate the proprietary metadata with the VMA metadata of the first process;

[0064] Obtain the VMA metadata of the second process, and associate the proprietary metadata with the VMA metadata of the second process; wherein, the VMA metadata uses the virtual address of the process as a unique identifier;

[0065] In response to a third process's request to release the shared memory space, the method of obtaining proprietary metadata of the shared memory space includes:

[0066] In response to a third process's request to release the shared memory space, the virtual address of the shared memory space carried in the release request is obtained;

[0067] After finding the VMMA metadata of the third process based on the virtual address, the proprietary metadata associated with the VMMA metadata of the third process is obtained.

[0068] Since the proprietary metadata does not correspond to a specific process, this embodiment utilizes the aforementioned virtual memory (vma) metadata to locate the proprietary metadata of the shared memory space and find the process metadata when a process releases the shared memory space. As described in the previous embodiment, each process corresponding to the shared memory space generates its corresponding vma metadata through the mmap() system call. The vma metadata uses the process's virtual address as a unique identifier. This embodiment associates each process's vma metadata with its proprietary metadata. When a third process initiates a release request, the corresponding vma metadata can be found through the virtual address of the shared memory space carried in the release request. Since the vma metadata is associated with the proprietary metadata, it can be accessed. Through this embodiment, even when proprietary metadata does not correspond to a specific process, the proprietary metadata can be quickly located when a process releases the shared memory space.

[0069] In some examples, this embodiment is applied to a first memory file system. In some scenarios, the memory file system needs to run continuously. If the memory file system needs to be updated, this embodiment provides the following implementation to ensure hot upgrades of the memory file system. For example, before the step of allocating shared memory space to the first process in response to a shared memory space request from the first process, the method may further include:

[0070] After being loaded into the operating system, a second memory file system currently running in the operating system was detected;

[0071] After obtaining the reference count of the operating system's configuration for the second memory file system and incrementing the value, a hot upgrade operation is performed on the second memory file system;

[0072] After the hot upgrade operation is completed, the reference count is released.

[0073] In this embodiment, the first memory file system refers to the new memory file system, and the second memory file system refers to the old memory file system that will be replaced. This embodiment configures the hot-upgrade function in the first memory file system. After the first memory file system is loaded into the operating system, it can detect whether an old memory file system already exists in the operating system. For example, the first memory file system can obtain the names and version information of each module currently running in the operating system. If a module with the same name is obtained, and the version information is compared, it can be determined that an old memory file system exists. For example, the operating system maintains metadata managing each running module through a linked list. By traversing the metadata in this linked list, it can be determined whether there is metadata for an old file system, thereby determining whether an old memory file system already exists. If not found, there is no old file system; if so, subsequent updates can be initiated. Based on this, the first memory file system can initiate subsequent updates. To ensure the normal operation of the hot upgrade, this embodiment first obtains the reference count configured by the operating system for the second memory file system and increments the value before performing the hot upgrade operation on the second memory file system; after completing the hot upgrade operation, the reference count is released. The kernel configures reference counts for some objects, indicating the number of times the object is currently used by a module. In this embodiment, a reference count is also configured for the memory file system, and the reference count of the second memory file system is incremented before hot upgrade to indicate the use of the second memory file system by the first memory file system. Therefore, the second memory file system can be prevented from being unloaded during hot upgrade and is protected during hot upgrade.

[0074] In some examples, performing a hot upgrade operation on the second memory file system may include:

[0075] Obtain the first registration location of the first memory file system in the operating system and the second registration location of the second memory file system in the operating system;

[0076] From the data of the second memory file system mounted under the second registration location, obtain key information related to the current operation of the second memory file system, update the obtained key information to the corresponding position of the data mounted under the first registration location, and then replace the data mounted under the second registration location with the data mounted under the first registration location.

[0077] The process of loading a memory file system into the operating system is essentially the registration process of the memory file system within the operating system. The kernel's configuration file records the registration information of each module. For the memory file system, after being loaded into the kernel, the kernel creates a structure named `struct file_system_type` and writes it into the configuration file. A linked list is then formed under this structure to link and manage various types of data within the memory file system. In this embodiment, the first registration location of the first memory file system and the second registration location of the second memory file system in the operating system can be obtained from the operating system's configuration file. Key information related to the current operation of the second memory file system is obtained from the data of the second memory file system mounted at the second registration location. After updating the corresponding positions of the data mounted at the first registration location with the obtained key information, the data mounted at the second registration location is replaced with the data mounted at the first registration location. Therefore, through the above embodiment, a hot upgrade operation for the second memory file system can be achieved. Optionally, the obtained key information can be flexibly configured according to actual needs. For example, it can be a hash bucket structure, a superblock, or a set of operation functions, etc. This embodiment does not limit this.

[0078] The following examples will further illustrate this.

[0079] Example 1: Shared Memory Architecture for Reserved Memory Scenarios

[0080] 1. First, to avoid the problem of the shared memory process causing excessive complexity in the management logic of the proprietary metadata mmap structure, for shared memory scenarios, when the shared memory mapping allocation is performed for the first time (i.e., when a process first requests shared memory space), a proprietary metadata mmap independent of the shared memory process is first established. This mmap inherits the characteristics of the original mmap but does not correspond to any specific process. This proprietary metadata mmap is used to associate with the process metadata of each process, that is, it is at the upper level of the process metadata; in this embodiment, it is referred to as the parent mmap. At this time, the proprietary metadata mmap is only established initially, and the information recorded in it is obtained and populated in subsequent steps.

[0081] a) Allocate a vma metadata, which is essentially fake data used only to simulate the use of the vma structure when mapping the original process, and does not correspond to a real process.

[0082] b) The virtual address range of the shared memory space needs to be recorded in the vma metadata. Since it does not correspond to a real process, this embodiment allocates a kernel-mode virtual address of the required size through high address memory and fills it into the corresponding field in the vma metadata.

[0083] c) Associate the vma with the corresponding file structure. Since the actual vma of each shared process has the same corresponding file, this association can be done on the first attempt.

[0084] Shared memory functionality is typically presented to processes via a memory file system. For shared files, the kernel sets up a `file` structure, which represents an open file. Each open file in the kernel has an associated `struct file` in kernel space. This structure is created by the kernel when the file is opened and passed to any function that operates on the file. The kernel releases this data structure after all instances of the file have been closed. This `file` structure can be associated with the process's VMA metadata.

[0085] d) Configure information in the VMA metadata, including but not limited to: page table size required for memory allocation, allocated nodes, allocation mode, and memory type (in this embodiment, this can be configured as a tag indicating a shared type).

[0086] e) The information in the vma metadata is sent to the reserved memory management module, which allocates the corresponding physical memory, establishes the relevant page table, records the allocation information in the mmap structure, and puts it into the mmap linked list.

[0087] f) Allocate a `share_info` structure and associate it with the parent `mmap` structure so that the shared information of subsequent shared memory processes can be linked to this `share_info`. This `share_info` structure serves as the head node of a linked list, used to link the process metadata of other processes, thus associating the metadata of each process with `mmap`. Optionally, if `mmap` reserves many fields for proprietary metadata, the `share_info` structure may not need to be created; instead, the fields of `share_info` can be directly stored in the reserved fields of `mmap`.

[0088] 2. When the shared process (i.e. the first or second process mentioned above) performs specific mapping, it can share all or part of the physical address range recorded by the parent mmap that was allocated beforehand. This can be understood as a sub-mapping of the parent mmap.

[0089] a) At this time, when the process mapping of shared memory (process mapping is that the shared memory space is mapped to the virtual address space of the process) is performed, the user-mode process still performs the mapping through the mmap() system call. The system call will eventually generate vma metadata containing the mapped virtual address range, and will also specify the starting location of the shared memory space. The shared memory space is represented by the offset relative to the starting physical address in the parent mmap.

[0090] b) Locate the parent mmap that was allocated in the previous step by using the shared file structure information corresponding to the vma metadata.

[0091] c) Determine the starting physical address paddr to be shared by using the information recorded in the shared parent mmap and the aforementioned shared offset.

[0092] d) Parse the virtual address range to be mapped based on the vma metadata, such as the starting virtual address vm_start and its size.

[0093] e) Establish process metadata for the process to record information shared this time. In this embodiment, it is called the shared_entry structure. This metadata records the corresponding virtual address range and the corresponding physical address range (which can be segmented and not contiguous), and is associated with the corresponding vma metadata of the process.

[0094] f) For the virtual address range and corresponding physical address recorded in shared_entry, establish the page table mapping for the process; (if the physical addresses are not contiguous, this process may need to be performed in segments multiple times).

[0095] g) Link the process metadata shared_entry to the parent mmap, which can be done by linking it to the shared_info structure in the parent mmap, thereby completing a shared memory mapping process.

[0096] h) Associate the parent mmap with the process's VMA metadata, for example, by mounting it to a private field of the process's VMA metadata, so that the two can look up each other later.

[0097] i) If multiple shared memory mappings are performed, the above process can be repeated; the parent mmap only needs to be allocated during the first mapping, and can be reused directly afterward; that is, when a process requests shared memory space for the first time, the parent mmap is created, and subsequent processes requesting shared shared memory space do not need to create the parent mmap again.

[0098] 3. To release a sub-mapping of shared memory space, the following procedure is performed:

[0099] a) Receive the release request of the process to be released, and parse the corresponding parent mmap structure from the vma metadata of the process to be released.

[0100] b) Access the parent mmap, find the process metadata shared_entry corresponding to the vma metadata from the shared_info shared information of the parent mmap structure, and remove it from the linked list;

[0101] c) Release the process's metadata shared_entry. The page table can be automatically cleaned up when the process is destroyed, so it does not need to be cleaned up separately here.

[0102] 4. If the last shared memory mapping process is ending the mapping, when all sub-mappings are unmapped, the shared_info structure will be cleaned up, the mapping of the parent mmap structure will be ended, the parent mmap will be released, and the memory will be returned to the memory management module.

[0103] Example 2: Memory-Shared File System Architecture with Reserved Memory

[0104] 1. In shared memory scenarios, the data is often presented to the outside world in the form of a file system to facilitate use by user-mode applications. Therefore, this embodiment also implements a reserved memory file system vmem_fs in the reserved memory.

[0105] 2. The reserved memory file system created is loaded into the operating system as a module and mounted to a specified path under the operating system.

[0106] Mounting refers to connecting the top-level directory of a file to a directory under the root directory of the operating system. Taking the Linux operating system as an example, in Linux, "everything is a file," and all files are placed in a tree-like directory structure with the Linux root directory as the root.

[0107] 3. The reserved memory file system provides a configuration interface (referred to as the proc interface in this embodiment) for processes to configure the memory size of the file system to be shared. This interface calls the step of establishing the parent mmap in Embodiment 1; and associates it with the inode structure corresponding to the path.

[0108] The inode structure is a structure created by the operating system for files. The operating system typically uses inode numbers to identify different files; the kernel does not use filenames, but rather inode numbers to identify files.

[0109] 4. Once loading is complete, the process can create shared files. Under the mount path, a file named "file" can be created using the "open()" system call.

[0110] 5. Then, the size of the memory to be shared, mmap_size, is passed through the mmap() system call for mapping. The file system vmem_fs will then calculate the offset based on the already shared memory size and establish a real shared mapping, mapping a segment of memory from the parent mmap. This will call the sub-mapping step in Example 1.

[0111] 6. Step 5 can be repeated to map all the memory specified by the path to a file.

[0112] 7. The offset and size of each file are recorded in the inode information of that file.

[0113] 8. Subsequent applications that need to share this memory only need to open the corresponding file to parse the mapped memory range and perform the corresponding sharing mapping.

[0114] 9. When releasing the file, if all applications that opened the file are closed, deleting the corresponding file will also delete the corresponding sub-mappings, and the sub-mapping deletion step in Example 1 will be called.

[0115] 10. After deleting all files in the path, delete the path. Deleting the path will also unmap the parent mmap; finally, the file system can be unmounted.

[0116] Example 3: Hot Upgrade Method for a Memory-Shared File System Architecture with Reserved Memory

[0117] 1. When the above vmem_fs is in use, if the memory file system needs to be updated, vmem_fs hot upgrade is required. When loading the new memory file system, if an old memory file system is found to exist, the hot upgrade logic will be triggered. It will first increase the reference count of the old memory file system (a counter set by the kernel, a non-zero count indicates the number of times the corresponding object is being used) to prevent it from being unloaded during the hot upgrade process.

[0118] 2. Traverse the memory file system through the file_systems file system header to find the original memory file system's registration point reg_type in the operating system.

[0119] Here, reg_type is a pointer variable to the execution registration point, which points to the subsequent old_type variable. The type of this pointer variable is file_system_type, which is a file system type registered with the kernel and contains information about this file system.

[0120] 3. Parse the old memory file system old_type from the registration point reg_type, and then mount the hash bucket structure fs_supers in the old file system to the new memory file system new_type.

[0121] Here, reg_type is a pointer to the registered file system type in the kernel, old_type is the old file system type registered; fs_supers is a field under the registered file system type file_system_type, which is the hash bucket that stores the superblock. This field contains a hash bucket, and each superblock in the hash bucket will store the paths of many files in the file system.

[0122] 4. Replace the new memory file system new_type in the file system's registry point list.

[0123] 5. Traverse the superblocks in the hash bucket structure fs_supers and associate the s_type field in each superblock with the new memory file system new_type.

[0124] The s_type field is a field under the superblock structure, which points to the file system type. Therefore, this field needs to be updated to the new file system's registration type new_type.

[0125] 6. Traverse each inode node in the old memory file system old_type, and associate the operation function set associated with its inode node with the operation function set of the current new memory file system. For example, update the i_op field of the directory node and update the i_fop field of the memory file node. At the same time, update the i_lock and i_rwsem fields of the inode field to the corresponding fields of the new memory file system function.

[0126] Each file in the file system has a corresponding inode structure. The i_op field under the inode structure records the set of operation functions for the file directory, and i_fop is the set of operation functions for the file. i_lock and i_rwsem are the lock fields of the inode. They are specially initialized and limited to the scope of the file system. Therefore, they need to be updated to the corresponding fields under the new file system.

[0127] 7. The memory file system function needs to record the file structure of the opened file each time it is opened, so that during hot upgrades, its f_op (operation function set) and the corresponding vma->vm_ops (each mmap operation of a file will generate vma metadata, and the vm_ops field under the vma metadata records the operation function set) are updated to the operation function set corresponding to the current new file system.

[0128] 8. Unload the proc interface corresponding to the old memory file system and load the proc interface of the new memory file system.

[0129] 9. Replace the old memory file system's management information vmem_fs in the reserved memory with the information of the new memory file system's functions.

[0130] 10. Remove the reference count from the old memory file system; at this point, the new memory file system is loaded, and the old memory file system can be removed.

[0131] Corresponding to the embodiments of the aforementioned shared memory processing method, this specification also provides embodiments of a shared memory processing apparatus and the computer equipment on which it is applied.

[0132] The embodiments of the shared memory processing apparatus described in this specification can be applied to computer devices, such as servers or terminal devices. The apparatus embodiments can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logically defined apparatus, it is formed by its processor reading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 3 The diagram shown is a hardware structure diagram of a computer device containing the shared memory processing device described in this specification, except... Figure 3 In addition to the processor 310, memory 330, network interface 320, and non-volatile memory 340 shown, the computer device where the shared memory processing device 331 is located in the embodiment may also include other hardware depending on the actual function of the computer device, which will not be described in detail here.

[0133] like Figure 4 As shown, Figure 4 This is a block diagram illustrating a shared memory processing apparatus according to an exemplary embodiment of this specification, the apparatus comprising:

[0134] The application processing module 41 is used to respond to the application request for shared memory space of the first process, allocate shared memory space for the first process, and create proprietary metadata for managing the shared memory space and process metadata for recording the process information of the first process.

[0135] The process metadata corresponding to the first process is associated with the proprietary metadata, and the process information of the first process is not written into the proprietary metadata.

[0136] The shared processing module 42 is used to respond to the second process's request to share the shared memory space, create process metadata that records the process information of the second process, and associate the process metadata of the second process with the proprietary metadata.

[0137] In some examples, the device further includes a release module for:

[0138] In response to a third process's request to release the shared memory space, the proprietary metadata of the shared memory space is obtained, and the process metadata of the third process is retrieved from the process metadata associated with the proprietary metadata and then released.

[0139] In some examples, the release module is also used for:

[0140] If the process metadata of the third process is released and the proprietary metadata of the shared memory space is not associated with the process metadata, the proprietary metadata is released and the shared memory space is reclaimed.

[0141] In some examples, the application processing module 41 is also used for:

[0142] Based on the size information carried in the application request, allocate a kernel-mode virtual address range and allocate shared memory space for the first process;

[0143] Obtain the physical address range of the shared memory space;

[0144] Generate proprietary metadata to manage the shared memory space. The proprietary metadata records physical address information representing the physical address range and virtual address information representing the kernel-mode virtual address range.

[0145] In some examples, the application processing module 41 is also used for:

[0146] Obtain the VMA metadata of the first process, and associate the proprietary metadata with the VMA metadata of the first process;

[0147] Obtain the VMA metadata of the second process, and associate the proprietary metadata with the VMA metadata of the second process; wherein, the VMA metadata uses the virtual address of the process as a unique identifier;

[0148] The release module executes the response to the third process's request to release the shared memory space, and obtains the proprietary metadata of the shared memory space, including:

[0149] In response to a third process's request to release the shared memory space, the virtual address of the shared memory space carried in the release request is obtained;

[0150] After finding the VMMA metadata of the third process based on the virtual address, the proprietary metadata associated with the VMMA metadata of the third process is obtained.

[0151] In some examples, the proprietary metadata includes fields that record identification information about the process;

[0152] The application processing module 41 is also used for:

[0153] Write a specified flag into the field of the identification information of the recorded process to prevent the process information of the first process from being written into the proprietary metadata; or,

[0154] The field of the identification information of the recorded process is set to empty so that the process information of the first process is not written into the proprietary metadata.

[0155] In some examples, the device is applied to a first memory file system, and the device further includes a hot-upgrade module for:

[0156] After being loaded into the operating system, a second memory file system currently running in the operating system was detected;

[0157] After obtaining the reference count of the operating system's configuration for the second memory file system and incrementing the value, a hot upgrade operation is performed on the second memory file system;

[0158] After the hot upgrade operation is completed, the reference count is released.

[0159] In some examples, the hot-upgrade module performs the hot-upgrade operation on the second memory file system, including:

[0160] Obtain the first registration location of the first memory file system in the operating system and the second registration location of the second memory file system in the operating system;

[0161] From the data of the second memory file system mounted under the second registration location, obtain key information related to the current operation of the second memory file system, update the obtained key information to the corresponding position of the data mounted under the first registration location, and then replace the data mounted under the second registration location with the data mounted under the first registration location.

[0162] The specific implementation process of the functions and roles of each module in the above-mentioned shared memory processing device can be found in the implementation process of the corresponding steps in the above-mentioned shared memory processing method, and will not be repeated here.

[0163] Accordingly, embodiments of this specification also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned shared memory processing method embodiments.

[0164] Accordingly, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of an embodiment of a shared memory processing method.

[0165] Accordingly, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of an embodiment of a shared memory processing method.

[0166] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0167] The above embodiments can be applied to one or more computer devices. The computer device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. The hardware of the computer device includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0168] The computer device can be any electronic product that can interact with the user, such as a personal computer, tablet computer, smartphone, personal digital assistant (PDA), game console, interactive network television (IPTV), smart wearable device, etc.

[0169] The computer equipment may also include network equipment and / or user equipment. The network equipment includes, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of hosts or network servers.

[0170] The network in which the computer device is located includes, but is not limited to, the Internet, wide area network, metropolitan area network, local area network, and virtual private network (VPN).

[0171] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0172] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0173] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0174] The terms "specific example" or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with the embodiments or examples, which are included in at least one embodiment or example of this specification. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0175] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this specification are indicated by the following claims.

[0176] It should be understood that this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the appended claims.

[0177] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for processing shared memory, the method comprising: In response to the request for shared memory space from the first process, shared memory space is allocated to the first process, and proprietary metadata for managing the shared memory space and process metadata for recording the process information of the first process are created; wherein, the process metadata corresponding to the first process is associated with the proprietary metadata, and the field recording the process identification information in the proprietary metadata is set to empty or written with a specified flag, so that the process information of the first process is not written to the proprietary metadata. In response to the second process's request to share the shared memory space, process metadata that records the process information of the second process is created, and the process metadata of the second process is associated with the proprietary metadata.

2. The method according to claim 1, further comprising: In response to a third process's request to release the shared memory space, the proprietary metadata of the shared memory space is obtained, and the process metadata of the third process is retrieved from the process metadata associated with the proprietary metadata and then released.

3. The method according to claim 2, further comprising: If the process metadata of the third process is released and the proprietary metadata of the shared memory space is not associated with the process metadata, the proprietary metadata is released and the shared memory space is reclaimed.

4. The method according to claim 1, wherein allocating shared memory space for the first process and creating proprietary metadata for managing the shared memory space includes: Based on the size information carried in the application request, allocate a kernel-mode virtual address range and allocate shared memory space for the first process; Obtain the physical address range of the shared memory space; Generate proprietary metadata to manage the shared memory space. The proprietary metadata records physical address information representing the physical address range and virtual address information representing the kernel-mode virtual address range.

5. The method according to claim 1, further comprising: Obtain the VMA metadata of the first process, and associate the proprietary metadata with the VMA metadata of the first process; Obtain the VMA metadata of the second process, and associate the proprietary metadata with the VMA metadata of the second process; wherein, the VMA metadata uses the virtual address of the process as a unique identifier; In response to a third process's request to release the shared memory space, the method of obtaining proprietary metadata of the shared memory space includes: In response to a third process's request to release the shared memory space, the virtual address of the shared memory space carried in the release request is obtained; After finding the VMMA metadata of the third process based on the virtual address, the proprietary metadata associated with the VMMA metadata of the third process is obtained.

6. The method of claim 1, wherein the method is applied to a first memory file system, and prior to the step of allocating shared memory space to the first process in response to a shared memory space request from the first process, the method further comprises: After being loaded into the operating system, a second memory file system currently running in the operating system was detected; After obtaining the reference count of the operating system's configuration for the second memory file system and incrementing the value, a hot upgrade operation for the second memory file system is performed; After the hot upgrade operation is completed, the reference count is released.

7. The method according to claim 6, wherein performing a hot upgrade operation on the second memory file system comprises: Obtain the first registration location of the first memory file system in the operating system and the second registration location of the second memory file system in the operating system; From the data of the second memory file system mounted under the second registration location, obtain key information related to the current operation of the second memory file system, update the obtained key information to the corresponding position of the data mounted under the first registration location, and then replace the data mounted under the second registration location with the data mounted under the first registration location.

8. A shared memory processing apparatus, the apparatus comprising: The application processing module is used to respond to the application request for shared memory space of the first process, allocate shared memory space for the first process, and create proprietary metadata for managing the shared memory space and process metadata for recording the process information of the first process; wherein, the process metadata corresponding to the first process is associated with the proprietary metadata, and the field recording the process identification information in the proprietary metadata is set to empty or written with a specified flag, so that the process information of the first process is not written to the proprietary metadata. The shared processing module is used to respond to the second process's request to share the shared memory space, create process metadata that records the process information of the second process, and associate the process metadata of the second process with the proprietary metadata.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

Images