Memory management

About: Memory management is a research topic. Over the lifetime, 16743 publications have been published within this topic receiving 312028 citations. The topic is also known as: memory allocation.

Non-Volatile Memory And Method With Control Data Management

Abstract: In a nonvolatile memory with block management system, critical data such as control data for the block management system is maintained in duplicates. Various methods are described for robustly writing and reading two copies of critical data in multi-state memory. In another aspect of the invention, a preemptive garbage collection on memory block containing control data avoids an undesirable situation where a large number of such memory blocks need be garbage collected at the same time.

Redundant memory mappings for fast access to large memories

Abstract: Page-based virtual memory improves programmer productivity, security, and memory utilization, but incurs performance overheads due to costly page table walks after TLB misses. This overhead can reach 50% for modern workloads that access increasingly vast memory with stagnating TLB sizes. To reduce the overhead of virtual memory, this paper proposes Redundant Memory Mappings (RMM), which leverage ranges of pages and provides an efficient, alternative representation of many virtual-to-physical mappings. We define a range be a subset of process's pages that are virtually and physically contiguous. RMM translates each range with a single range table entry, enabling a modest number of entries to translate most of the process's address space. RMM operates in parallel with standard paging and uses a software range table and hardware range TLB with arbitrarily large reach. We modify the operating system to automatically detect ranges and to increase their likelihood with eager page allocation. RMM is thus transparent to applications. We prototype RMM software in Linux and emulate the hardware. RMM performs substantially better than paging alone and huge pages, and improves a wider variety of workloads than direct segments (one range per program), reducing the overhead of virtual memory to less than 1% on average.

Fat analysis for optimized sequential cluster management

Abstract: Techniques for managing data in a non-volatile memory system (e.g., Flash Memory) are disclosed. A controller can use information relating to a host's file system, which is stored by the host on non-volatile memory, to determine if one or more clusters (or sectors with clusters) are currently allocated. The controller can use the information relating to the host's file system to identify when the host is sending data to the next free cluster and to store such data in a sequential format by copying data from other locations in the non-volatile memory.

Memory array search engine

Abstract: Systems and/or methods that facilitate a search of a memory component(s) to locate a desired logical block address (LBA) associated with a memory location in a memory component are presented. Searches to locate a desired LBA(s) in a memory component(s) associated with a processor component are offloaded and controlled by the memory component(s). A search component searches pages in the memory array to facilitate locating a page of data associated with an LBA stored in the memory component. The search component can retrieve a portion of a page of data in a block in the memory component to facilitate determining whether the page contains an LBA associated with a command based in part on command information. The search component can search pages in the memory component until a desired page is located or a predetermined number of searches is performed without locating the desired page.

Supporting x86-64 address translation for 100s of GPU lanes

Abstract: Efficient memory sharing between CPU and GPU threads can greatly expand the effective set of GPGPU workloads. For increased programmability, this memory should be uniformly virtualized, necessitating compatible address translation support for GPU memory references. However, even a modest GPU might need 100s of translations per cycle (6 CUs * 64 lanes/CU) with memory access patterns designed for throughput more than locality.