WO2017142525A1 - Attribution d'une zone d'une région de mémoire partagée - Google Patents

Attribution d'une zone d'une région de mémoire partagée Download PDF

Info

Publication number
WO2017142525A1
WO2017142525A1 PCT/US2016/018227 US2016018227W WO2017142525A1 WO 2017142525 A1 WO2017142525 A1 WO 2017142525A1 US 2016018227 W US2016018227 W US 2016018227W WO 2017142525 A1 WO2017142525 A1 WO 2017142525A1
Authority
WO
WIPO (PCT)
Prior art keywords
zone
processes
shared memory
memory region
allocation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2016/018227
Other languages
English (en)
Inventor
Haris Volos
Jun Li
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Priority to PCT/US2016/018227 priority Critical patent/WO2017142525A1/fr
Publication of WO2017142525A1 publication Critical patent/WO2017142525A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1024—Latency reduction

Definitions

  • a distributed system can include a number of compute nodes that can execute program code.
  • Each instance of a program code executed on a compute node can be referred to as a process, such that multiple processes are executed in the compute nodes.
  • data generated by one process can be shared with another process.
  • Fig. 1 is a block diagram of an example distributed system that includes a distributed arrangement of compute nodes and a shared memory region, in accordance with some implementations.
  • FIG. 2 is a flow diagram of an example flow according to some embodiments.
  • Figs. 3A-3C illustrate an example of opening a shared memory heap and allocating blocks from the shared memory heap, according to some implementations.
  • FIG. 4 is a flow diagram of an example flow according to further
  • Fig. 5 is a block diagram of an example system according to some implementations.
  • FIG. 6 is a block diagram of an example storage medium storing
  • Processes executing on compute nodes can share data with one another.
  • the sharing of data can be performed using network
  • Such sharing techniques involve copying data from private memory associated with each process to a shared medium, such as a network, a shared buffer, or a shared file. Such copying of the data from private memory to the shared medium is associated with processing and communications overhead that can reduce overall system
  • the sharing of data between processes executing on compute nodes can be
  • a shared memory region can refer to a memory region that is implemented in memory media that is associated with respective compute nodes.
  • the memory media can be implemented with memory devices or portions of memory devices, which can include non-volatile memory devices (e.g. memristor memory devices, phase-change memory devices, and so forth) and/or volatile memory devices such as dynamic random access memory (DRAM) devices.
  • non-volatile memory devices e.g. memristor memory devices, phase-change memory devices, and so forth
  • DRAM dynamic random access memory
  • a memory region of the storage space provided by the memory media can refer to at least a portion of the overall storage space that is useable by processes running in a system. Note that the portion of the overall storage space can be made up of a single contiguous region or multiple regions in the overall storage space.
  • a shared memory region can be referred to as a shared memory heap.
  • a memory heap (or more simply, heap) refers to a pool of memory that can be allocated for use, where some parts of the heap are free and available for future allocation to processes, while other parts of the heap are currently allocated to respective processes.
  • a "process” can refer to an instance of program code (machine-readable instructions such as software or firmware) that can be executed on a compute node.
  • a compute node can include a computer, multiple computers, a processor, multiple processors, a core (or multiple cores) of a multi-core processor, or any other hardware processing circuit. Multiple processes can execute on a compute node.
  • Fig. 1 shows a block diagram of an example distributed system 100 that includes multiple compute nodes 102-1 , 102-2, 102-3, and 102-4. Although four compute nodes are shown in the example of Fig. 1 , it is noted that in other examples, different numbers of compute nodes can be provided. Multiple processes can be executed on the respective multiple compute nodes 102-1 , 102-2, 102-3, and 102-4. For example, processes 104-1 and 104-2 can execute on the compute node 102-1 , process 104-3 can execute on the compute node 102-2, a process 104-4 can execute on the compute node 102-3, and processes 104-5, 104-6, and 104-7 can execute on the compute node 102-4.
  • processes 104-1 and 104-2 can execute on the compute node 102-1
  • process 104-3 can execute on the compute node 102-2
  • a process 104-4 can execute on the compute node 102-3
  • processes 104-5, 104-6, and 104-7 can execute on the compute node 102-4.
  • the distributed system 100 also includes a shared memory region 106 (e.g. a shared memory heap), which is accessible by each compute node 102-1 to 102-4.
  • a shared memory region 106 is directly accessible by each compute node 102-1 to 102-4, where directly accessible can refer to a compute node being able to issue a memory command over a memory bus to access a location in the shared memory region 106.
  • the shared memory region 106 can be partitioned or divided into multiple zones 1 10-1 , 1 10-2, 1 10-3, and 1 10-4. Although four zones are shown in Fig. 1 , it is noted that in further examples, the shared memory region 106 can be divided into a different number of zones. Each zone can refer to a contiguous region of the shared memory region 106. Each zone of the shared memory region 106 can be physically allocated from a respective memory medium associated with a corresponding compute node. Note that the shared memory region 106 can be implemented with multiple memory media that can be associated with corresponding compute nodes 102-1 to 102-4.
  • the memory media can be provided at different locations within the distributed system 100, with each memory medium being more closely associated with one of the compute nodes than another of the compute nodes.
  • a first memory medium can be more closely associated with a first compute node than to other compute nodes.
  • a memory medium is more closely associated with a first compute node than a second compute node if the first compute node can access the memory medium with lower latency than the second compute node (in other words, the access time involved in the first compute node accessing the memory medium is less than the access time involved when the second compute node accesses the memory medium).
  • a given memory medium that is more closely associated with a given compute node can be provided in the same computing platform, on a common integrated circuit die, or otherwise is interconnected by a relatively lower latency communications link to the given compute node.
  • a zone allocated from a memory medium that is more closely associated to a given compute node can be accessed by the given compute node with lower latency than by another compute node. Stated differently, different zones of the shared memory region 106 can be accessed with different latencies by a particular compute node.
  • the arrangement of the shared memory region 106 is a non-uniform memory access (NUMA) arrangement, in which different compute nodes may have different access latencies to different memory portions of the shared memory region 106.
  • NUMA non-uniform memory access
  • Each zone is owned by a single process, i.e. the process that requested allocation of the zone.
  • the zone is accessible concurrently by multiple processes that execute on the corresponding compute nodes 102-1 to 102-4, such that data stored in the zone can be shared by the multiple processes.
  • the multiple processes are able to perform both read access and write access of a zone owned by a particular process.
  • the zones 1 10-1 to 1 10-4 are thus shared zones that allow the
  • each process can write data to a shared zone using a direct memory write access, and another process can read the data written to the shared zone using a direct memory read access.
  • a private memory region e.g. private heap
  • a zone is owned by a process if the process requested allocation of the zone and that has the ability to de-allocate (free) the zone, such that the freed zone can be allocated to another process.
  • each zone is a fixed-size contiguous region of the shared memory region 106, such that the different zones that are allocated for respective processes all have the same fixed size. In other examples, different zones can have different sizes.
  • a zone can further be split into smaller blocks.
  • the blocks split from a zone can have arbitrary sizes, such that each zone can be split into arbitrary sized blocks.
  • the shared memory region 106 is also associated with a memory manager 108 that can perform a number of different tasks.
  • the memory manager 108 can be implemented as a combination of hardware processing circuitry and program code that can provide respective tasks.
  • the hardware processing circuit can include a microprocessor, a microcontroller, a core of a microprocessor, a programmable gate array, a programmable integrated circuit, or any other hardware processing circuit.
  • the memory manager 108 can manage read and/or write access of the shared memory region 106.
  • the memory manager 108 includes a locality-aware allocation interface 1 12 that is accessible by processes executing on the compute nodes 102-1 to 102-4 to allocate a portion (e.g. a block) of the shared memory region 106.
  • the locality-aware allocation interface 1 12 can also be used by a process to de-allocate (free) a memory portion (e.g. a block) of the shared memory region 106.
  • An "allocation interface" can refer to a component that is accessible by a process to request that an action be performed with respect to the shared memory region 106.
  • a locality-aware allocation of a block of the shared memory region 106 can refer to an allocation in which the block that is allocated has a specified proximity to a given compute node of the compute nodes 102-1 to 102-4 (e.g. the block is allocated from a zone that can be accessed by a first compute node with lower latency than another zone).
  • the specified proximity can be indicated by a locality indication provided with a memory allocation request, such as a call of a malloc() routine.
  • the locality indication can be in the form of a hint or other information that can specify or suggest that the block is to be allocated from a zone that is more closely associated with a given compute node.
  • the locality indication can be in the form of an identifier of a compute node, an identifier of a process, location information associated with a compute node, or any other information that can be used to derive a target locality for the block that is to be allocated.
  • a locality-aware allocation of a block can allocate the block from a zone that is more closely associated with a compute node on which the process that requested the allocation is executed. For example, if the process requesting the allocation of the block is running on compute node 102-1 , then the locality-aware allocation can allocate the block from the zone 1 10-1 that is more closely associated with the compute node 102-1 .
  • the locality-aware allocation interface 1 12 can be part of a library of methods (a "method" can refer to machine-readable instructions) that can be called by processes to allocate and de-allocate portions of the memory region 106.
  • a "method" can refer to machine-readable instructions
  • An example of such a library is discussed in connection with Figs. 3A-3C further below.
  • a method to allocate a block of the shared memory region 106 can be a malloc() method, while a method to de-allocate a block of the shared memory region 106 can be a free() method.
  • the malloc() method can allocate a block of a specified size.
  • the requested memory block of the specified size is allocated for the requesting process, and a pointer that refers to the allocated memory block can be returned to the process for use by the process in accessing the allocated memory block.
  • This pointer can also be communicated from the allocating process to a second process, for the second process to use the pointer in accessing the allocated memory block.
  • the free() method when invoked by a process, frees a memory block referred to by a specified pointer.
  • another method can be used to perform bulk de-allocation of blocks (discussed further below).
  • the locality-aware allocation interface 1 12 can provide other routines or functions that can be invoked by a process to perform allocation of a memory portion or de-allocation of a memory portion, among other tasks.
  • Fig. 2 is a flow diagram of an example flow 200 that can be performed in accordance with some implementations.
  • the flow 200 can be performed by the distributed system 100 that includes the compute nodes 102-1 to 102-4 and the memory manager 108, or by a different system that includes a computer or an arrangement of multiple computers.
  • the flow 200 includes executing (at 202) multiple processes on multiple compute nodes, such as the compute nodes 102-1 to 102-4 of Fig. 1 .
  • the flow 200 further includes allocating (at 204), by a first process of the multiple processes, a first zone in a shared memory region (e.g. the shared memory region 106), where the shared memory region is partitionable into multiple zones, and where the first zone is owned by the first process and is accessible by the multiple processes.
  • the allocating of the first zone can be performed in response to the first process calling the locality-aware allocation interface 1 12 to perform an allocation from the shared memory region 106.
  • the allocating of the first zone includes selecting (at 206) the first zone from the multiple zones based on the specified proximity of the first zone to a given compute node of the compute nodes.
  • FIG. 3A-3C illustrate an example relating to use of a shared memory region (such as the shared memory region 106 of Fig. 1 ).
  • the shared memory region is referred to as a shared heap.
  • Two user processes 302-A and 302-B are depicted, where each user process corresponds to an executed instance of application code 304-A and 304-B, respectively.
  • Figs. 3A-3C show an example in which the processes that can allocate and use portions of a shared memory region are user processes, it is noted that in other examples, other types of processes can allocate and use portions of a shared memory region.
  • a user process refers to a process generated due to execution of an application or other program code in the user space of a system.
  • the user space of a system is contrasted to a kernel space of an operating system, where the kernel space is reserved for running code of the kernel of an operating system.
  • a shared heap is backed by (i.e. stored in) a shared heap file 306 that is divided into multiple zones (zone 0, zone 1 , zone 2, and zone 3 shown in Fig. 3A).
  • the shared heap can be implemented with multiple shared heap files (e.g. one shared heap file per zone or each shared heap file including multiple zones).
  • the shared heap file 306 is stored in a shared file system, where the shared file system is stored in memory.
  • the shared heap includes (1 ) metadata describing which regions of the heap are allocated and which are free (for allocation), and (2) data stored by the user in the allocated memory regions.
  • a user process can open a shared heap by making a call 308 to a heap library 308-A.
  • the heap library 308-A is an instance of a heap library that is part of the user process 302-A. Multiple instances of the heap library can be invoked in respective different user processes.
  • the heap library can include various methods that can be called by a user process.
  • one method is a HEAP_OPEN method, which is invoked by the call 308.
  • the call 308 of the HEAP_OPEN method causes the shared heap file 306 to be memory mapped (310) as a shared heap 312-A into a virtual address space of the user process 302-A.
  • the shared heap 312-A in the virtual address space of the user process 302-A is an instance of the shared heap file 306.
  • the user process 302-B has not yet opened a shared heap in the virtual address space of the user process 302-B.
  • Memory-mapping the shared heap file 306 refers to creating (such as by an operating system) a segment (e.g. the shared heap 312-A) in the virtual address space of the caller (in this case the user process 302-A), and then assigning each memory byte of the segment to a byte of the shared heap file 306.
  • the assignment can be done in a direct byte-to-byte fashion, meaning that byte 0 of the segment corresponds to byte 0 of the shared heap file 306, byte 1 of the segment
  • a handle that identifies the shared heap 312-A is created, where the handle can be used by the user process 302-A to allocate or de-allocate memory from the shared heap 312- A.
  • a handle can refer to any value that can be used to identify the shared heap 312- A.
  • the handle can carry a generation indication that provides an indication of a respective instance (generation) of the shared heap.
  • the generation indication is in the form of a generation identifier (e.g. a generation number such as a global integer) to identify the specified generation of the shared heap.
  • a generation includes a collection of zones and blocks allocated during the instantiation of the shared heap. Such allocations and data stored in the allocated zones and blocks survive between heap generations. Thus, blocks allocated and data stored in these blocks during the lifetime of a previous generation can be accessed by later generations.
  • each opening of a shared heap by a user process causes a new generation of the shared heap to be created, and thus a new generation identifier is assigned.
  • the shared heap 312-A that is opened by the user process 302-A can have a generation identifier of 1 . If the user process 302-A exits and then re-opens the shared heap, then the generation identifier is incremented to identify a next generation of the shared heap. As a further example, if the user process 302-B later opens the shared heap, the generation identifier is incremented again for the shared heap opened by the user process 302-B.
  • the HEAP_OPEN method locks the zone by atomically writing the unique generation identifier.
  • the unique generation identifier can be written into the metadata of the zone.
  • the user process 302-A can make a call 314 (as shown in Fig. 3B) to allocate a block from the shared heap 312-A.
  • the call 314 to allocate the block from the shared heap 312-A can be a call to a malloc() method in the heap library 308-A.
  • An example of the malloc() method is set forth below: void * malloc(size_t size, int numa_node_hint).
  • the called malloc() method passes in two input parameters: size_t (which specifies the desired size of the block to be allocated), and numa_node_hint (which is a hint that provides an indication of a target locality of the block to be allocated).
  • zone 0 satisfies the locality indicate by numa_node_hint, and thus zone 0 of the shared heap 312-A is allocated to the user process 302 -A, which has an identifier of 5 in the example.
  • Zone 0 is associated with metadata that indicates that zone 0 is owned by a user process with identifier 5.
  • the block of size size_t is allocated in zone 0 in response to the call 314. Once the block is allocated, a pointer to the block can be returned to the user process 302-A, for use in accessing data in the block.
  • the pointer can include a relocatable base-relative smart pointer for logically addressing (naming) an allocated block.
  • the base-relative smart pointer our pointers is relocatable, which means that the shared heap does not have to be memory mapped into the same virtual address range in each process.
  • a logical address represents an offset relative to the base of the virtual address region that maps the shared heap so that the heap can be memory mapped to different virtual address regions in the processes.
  • the user process 302-A can invoke additional calls to allocate further blocks from the shared heap 312-A. For each such additional call, if there is sufficient space in zone 0 to allocate the further block of memory, then the block can be allocated from zone 0. However, if there is insufficient space in zone 0 to satisfy the request to allocate the further block, then a new zone can be allocated to the user process 302-A, and this new zone can be associated with owner 5.
  • an additional call to allocate a further block can include a different numa_node_hint value, which can cause a different zone to be allocated to the user process 302-A even though zone 0 (already allocated to the user process 302-A) may have sufficient space for the further block.
  • Fig. 3C shows an example where the user process 302-B has issued a call 315 to open the shared heap (represented as 312-B).
  • a memory mapping 316 is performed between the shared heap file 306 and the shared heap 312-B in the virtual address space of the user process 302-B.
  • the generation identifier associated with the shared heap file 306 can be incremented to identify a new generation of the shared heap.
  • zone 2 is allocated to the user process 302-B.
  • Zone 2 is associated with metadata that indicates that zone 2 is owned by a user process with identifier 6, which is the identifier of the user process 302-B in the example.
  • Ownership of a zone is transient in that the heap library relinquishes ownership of a zone as soon as the owning user process exits.
  • Fig. 4 is a flow diagram of an example flow 400 according to further implementations.
  • the flow 400 can be performed by the distributed system 100 of Fig. 1 , or by a different system that includes a computer or an arrangement of multiple computers.
  • the flow 400 includes concurrently allocating (at 402), by multiple processes executing on multiple compute nodes, respective zones of a shared memory region, where a first zone of the zones allocated by a first process is owned by the first zone and is accessible by the multiple processes, and a second zone allocated by a second process is owned by the second zone and is accessible by the multiple processes.
  • the allocating of the respective zones can be performed in response to calls by the processes to the locality-aware allocation interface 1 12, for example.
  • the flow 400 further includes performing (at 404), by a memory manager (e.g. memory manager 108 in Fig. 1 ), bulk de-allocation of blocks of the shared memory region that are associated with a given generation of the shared memory region.
  • Bulk de-allocation can be performed when a user process invokes a call to a bulk-free() method that is part of the heap library (e.g. 308-A or 308-B illustrated in Fig. 3A).
  • Performing bulk de-allocation can be more efficient when attempting to free multiple blocks, as compared to having to make multiple calls to free individual blocks.
  • Bulk de-allocation involves the de-allocation of multiple blocks that are associated with a given generation, as identified by a generation identifier.
  • Bulk de- allocation can be performed when a shared memory region is opened by a process, which can be performed when a process is started (e.g. initially started or restarted due to a previous crash of the process).
  • the bulk de-allocation can be part of a recovery procedure to recover from the crash.
  • the bulk de-allocation can be performed at other times or in response to other events.
  • the memory manager can bulk-free blocks by zeroing all zone metadata associated with zones associated with a given generation identifier, and then the ownership of such zones can be released by zeroing the zone blocks.
  • Zeroing zone metadata refers to deleting or otherwise rendering the zone metadata invalid such that the zone metadata can be over-written.
  • Zeroing a block refers to deleting the content of the block or otherwise rendering the block content invalid so that it can be over-written with other data.
  • a call to free a specific block can be made by a process, such as by using a free() method in the heap library.
  • the free() method can locate the zone containing the block, and if the zone is owned by the process that invoked the request to free the block, then the block can be freed by the memory manager. Otherwise, deallocation fails, and the user process would have to direct the call to free the block to the user process owning the zone.
  • Fig. 5 is a block diagram of an example system according to further implementations.
  • the system includes a shared memory region 502, which can be similar to the shared memory region 106 of Fig. 1.
  • the system 500 further includes multiple compute nodes 504-1 and 504-2, and respective processes 506-1 and 506- 2 are executed by the respective compute nodes 504-1 and 504-2.
  • a first process of the multiple processes (506-1 and 506-2) can use a locality-aware allocation interface 508 to perform locality-aware allocation of a first zone of the shared memory region 502, where the first zone is owned by the first process and is accessible by the first process 506-1 and the second process 506-2.
  • the locality- aware allocation of the first zone is to allocate the first zone that has a specified proximity to a given compute node of the compute nodes 504-1 and 504-2.
  • Fig. 6 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 600 that stores instructions that upon execution cause a system to perform various tasks.
  • the instructions include process execution instruction 602 to execute multiple processes on multiple compute nodes.
  • the instructions further include zone allocation instructions 604 to allocate, by a first process of the multiple processes, a first zone in a shared memory region that is partitioned into multiple zones, where the first zone is owned by the first process and is accessible by the multiple processes.
  • the zone allocation instructions can select the first zone from multiple zones based on a specified proximity of the first zone to a given compute node of the compute nodes.
  • the storage medium 600 can include one or multiple different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices.
  • semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories
  • magnetic disks such as fixed, floppy and removable disks
  • other magnetic media including tape optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices.
  • CDs compact disks
  • DVDs digital video disks
  • Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture).
  • An article or article of manufacture can refer to any manufactured single component or multiple components.
  • the storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Dans certains exemples, un système comprend une région de mémoire partagée, une pluralité de nœuds de calcul et une pluralité de processus pouvant être exécutés dans la pluralité de nœuds de calcul. Un premier processus de la pluralité de processus consiste à : utiliser une interface d'attribution pour effectuer une attribution sensible à l'emplacement d'une première zone de la région de mémoire partagée, la première zone étant détenue par le premier processus et accessible par le premier processus et un second processus de la pluralité de processus. L'attribution sensible à l'emplacement de la première zone permet d'attribuer la première zone qui comprend une proximité spécifiée par rapport à un nœud de calcul donné de la pluralité de nœuds de calcul.
PCT/US2016/018227 2016-02-17 2016-02-17 Attribution d'une zone d'une région de mémoire partagée Ceased WO2017142525A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2016/018227 WO2017142525A1 (fr) 2016-02-17 2016-02-17 Attribution d'une zone d'une région de mémoire partagée

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/018227 WO2017142525A1 (fr) 2016-02-17 2016-02-17 Attribution d'une zone d'une région de mémoire partagée

Publications (1)

Publication Number Publication Date
WO2017142525A1 true WO2017142525A1 (fr) 2017-08-24

Family

ID=59625382

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/018227 Ceased WO2017142525A1 (fr) 2016-02-17 2016-02-17 Attribution d'une zone d'une région de mémoire partagée

Country Status (1)

Country Link
WO (1) WO2017142525A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021003002A1 (fr) * 2019-07-03 2021-01-07 Microsoft Technology Licensing, Llc Désaffectation de mémoire à travers une limite de confiance
EP3690651A4 (fr) * 2017-10-13 2021-04-14 Huawei Technologies Co., Ltd. Procédé et système pour communication interprocessus
US20230325239A1 (en) * 2021-02-12 2023-10-12 University Of Massachusetts A system and method for memory allocation and management in non-uniform memory access architecture computing environments
US20240054015A1 (en) * 2022-08-11 2024-02-15 Next Silicon Ltd Memory management in a multi-processor environment

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093628A1 (en) * 2001-11-14 2003-05-15 Matter Eugene P. Memory adaptedt to provide dedicated and or shared memory to multiple processors and method therefor
US20080195719A1 (en) * 2007-02-12 2008-08-14 Yuguang Wu Resource Reservation Protocol over Unreliable Packet Transport
US20100095089A1 (en) * 2008-10-14 2010-04-15 Samsung Electronics Co., Ltd. Multiprocessor system with multiport memory
US20100161929A1 (en) * 2008-12-18 2010-06-24 Lsi Corporation Flexible Memory Appliance and Methods for Using Such
US20160034398A1 (en) * 2014-07-29 2016-02-04 Freescale Semiconductor, Inc. Cache-coherent multiprocessor system and a method for detecting failures in a cache-coherent multiprocessor system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093628A1 (en) * 2001-11-14 2003-05-15 Matter Eugene P. Memory adaptedt to provide dedicated and or shared memory to multiple processors and method therefor
US20080195719A1 (en) * 2007-02-12 2008-08-14 Yuguang Wu Resource Reservation Protocol over Unreliable Packet Transport
US20100095089A1 (en) * 2008-10-14 2010-04-15 Samsung Electronics Co., Ltd. Multiprocessor system with multiport memory
US20100161929A1 (en) * 2008-12-18 2010-06-24 Lsi Corporation Flexible Memory Appliance and Methods for Using Such
US20160034398A1 (en) * 2014-07-29 2016-02-04 Freescale Semiconductor, Inc. Cache-coherent multiprocessor system and a method for detecting failures in a cache-coherent multiprocessor system

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11892953B2 (en) 2017-10-13 2024-02-06 Huawei Technologies Co., Ltd. Interprocess communication method and interprocess communications system
EP3690651A4 (fr) * 2017-10-13 2021-04-14 Huawei Technologies Co., Ltd. Procédé et système pour communication interprocessus
US11593169B2 (en) 2019-07-03 2023-02-28 Microsoft Technology Licensing, Llc Memory deallocation across a trust boundary
WO2021003002A1 (fr) * 2019-07-03 2021-01-07 Microsoft Technology Licensing, Llc Désaffectation de mémoire à travers une limite de confiance
US20230168933A1 (en) * 2019-07-03 2023-06-01 Microsoft Technology Licensing, Llc Memory deallocation across a trust boundary
CN114041119A (zh) * 2019-07-03 2022-02-11 微软技术许可有限责任公司 跨越信任边界的存储器解除分配
US12099875B2 (en) * 2019-07-03 2024-09-24 Microsoft Technology Licensing, Llc. Memory deallocation across a trust boundary
US20240411598A1 (en) * 2019-07-03 2024-12-12 Microsoft Technology Licensing, Llc Memory deallocation across a trust boundary
EP4675434A1 (fr) * 2019-07-03 2026-01-07 Microsoft Technology Licensing, LLC Désaffectation de mémoire à travers une limite de confiance
CN114041119B (zh) * 2019-07-03 2026-03-31 微软技术许可有限责任公司 跨越信任边界的存储器解除分配
US20230325239A1 (en) * 2021-02-12 2023-10-12 University Of Massachusetts A system and method for memory allocation and management in non-uniform memory access architecture computing environments
US12314761B2 (en) * 2021-02-12 2025-05-27 University Of Massachusetts System and method for memory allocation and management in non-uniform memory access architecture computing environments
US20240054015A1 (en) * 2022-08-11 2024-02-15 Next Silicon Ltd Memory management in a multi-processor environment
US12020069B2 (en) * 2022-08-11 2024-06-25 Next Silicon Ltd Memory management in a multi-processor environment

Similar Documents

Publication Publication Date Title
US5809554A (en) User control of multiple memory heaps
US9852054B2 (en) Elastic caching for Java virtual machines
CN102819497B (zh) 一种内存分配方法、装置及系统
US8478931B1 (en) Using non-volatile memory resources to enable a virtual buffer pool for a database application
EP2985702A1 (fr) Méthode et dispositif de traitement de données, et système informatique
US20090172337A1 (en) Cooperative mechanism for efficient application memory allocation
US20240078187A1 (en) Per-process re-configurable caches
WO2024230779A1 (fr) Procédé et système d'accès aux fichiers, dispositif électronique et support de stockage lisible par machine
KR20110050457A (ko) 플래시 메모리 저장 장치에서 동적 메모리 할당에 의해 일어나는 자기 축출을 회피하는 방법
US8185693B2 (en) Cache-line aware collection for runtime environments
US11061609B2 (en) Distributed memory object method and system enabling memory-speed data access in a distributed environment
CN118210622B (zh) 一种内存分配方法及计算设备
US12314761B2 (en) System and method for memory allocation and management in non-uniform memory access architecture computing environments
CN116302598A (zh) 共享内存的处理方法、装置、计算机设备及存储介质
CN113535392B (zh) 基于cma实现支持大内存连续分配的内存管理方法及系统
US20140289739A1 (en) Allocating and sharing a data object among program instances
CN117435343A (zh) 内存的管理方法及装置
US9552295B2 (en) Performance and energy efficiency while using large pages
JP2024527054A (ja) 動的割当可能な物理的にアドレス指定されるメタデータストレージ
CN110019083A (zh) 分布式文件系统的存储方法、装置、电子设备及存储介质
US7840772B2 (en) Physical memory control using memory classes
CN115729702A (zh) 应用程序内存配置方法、电子设备、计算机存储介质
US7159094B1 (en) Kernel memory defragmentation method and apparatus
CN113448897A (zh) 适用于纯用户态远端直接内存访问的数组结构及优化方法
EP1971922B1 (fr) Architecture de memoire et procede d'acces

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16890824

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16890824

Country of ref document: EP

Kind code of ref document: A1