Hardware-based memory compression

Abstract

To provide a memory compression method and a memory for reducing the size of an entry within a segment corresponding to a sub-segment and realizing a low-meta-data overhead in a compression memory divided into multiple segments.SOLUTION: A method divides a compression memory into multiple segments, divides the respective segments into multiple sub-segments, compresses the respective segments within a non-compression data space to blocks within a compression data space, first determines a corresponding entry when receiving a read request to the sub-segments within the segments in the compression memory on the basis of first level address mapping between the sub-segments and the entry, and then determines a corresponding block on the basis of second level address mapping between the entry and the block.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] One embodiment of the present invention, for example, relates to hardware-based memory compression. [Background technology]

[0002]

[0001] Memory refers to a component of a computing device that stores information for immediate use in the computing system, and is also called primary storage. Memories such as random access memory (RAM) provide slow-to-access information but operate at high speeds, in contrast to storage that offers higher capacity. Generally, there are two main types of memory, such as volatile memory and non-volatile memory, and examples of volatile memory include dynamic random access memory (DRAM), static random access memory (SRAM), etc.

[0003]

[0002] Memory compression is a memory management technique that utilizes data compression to reduce the size of data stored in memory, and can include software-based memory compression and hardware-based memory compression. Software-based memory compression is already used in operating systems, where compression and decompression processes are typically implemented by a processor or processing unit. Hardware-based memory compression is instead implemented through hardware, where compression and decompression processes can be handled by hardware components. Summary of the Invention [Problem to be solved by the invention]

[0004] One embodiment of the present invention, for example, relates to hardware-based memory compression. [Means for solving the problem]

[0005]

[0003] In an embodiment of the present disclosure, an approach for hardware-based memory compression is provided. A compressed memory according to an embodiment of the present disclosure is divided into multiple segments, each segment is divided into multiple subsegments, and each subsegment in the uncompressed data space is compressed into one or more blocks in the compressed data space. When a read request to a subsegment in a segment in the compressed memory is received, a corresponding entry is first determined based on a first-level address mapping between the subsegment and the entry, and then a corresponding block is determined based on a second-level address mapping between the entry and the block. In accordance with an embodiment of the present disclosure, the use of two-level address mapping reduces the size of the entry, thereby achieving low metadata overhead. Furthermore, the proposed data layout for the compressed memory can achieve stable and fast block allocation in the compressed memory.

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0007]

[0005] The above and other features, advantages, and aspects of the embodiments of the present disclosure will become more apparent by describing the present disclosure in more detail with reference to the drawings. In the drawings, the same or similar reference numerals refer to the same or similar elements. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 6 is a block diagram of a computing device / server in which one or more embodiments of the present disclosure may be implemented. [Figure 2]

[0007] FIG. 1 illustrates an exemplary architecture using tile-based compressed memory, according to an embodiment of the present disclosure. [Figure 3] 8 is a flowchart of a method for hardware-based memory compression according to an embodiment of the present disclosure. [Figure 4]

[0009] FIG. 2 is a schematic diagram of a two-level address mapping of tiles according to an embodiment of the present disclosure. [Figure 5]

[0010] FIG. 2 is a schematic diagram of an example data compression from a paragraph into one or more blocks according to an embodiment of the present disclosure. [Figure 6]

[0011] FIG. 2 illustrates an example data layout within a tile, according to an embodiment of the present disclosure. [Figure 7]

[0012] 1 is a flowchart of a method for writing compressed data to tiles according to an embodiment of the present disclosure. [Figure 8]

[0013] FIG. 2 illustrates an example hardware architecture for implementing memory compression, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0009]

[0014] Embodiments of the present disclosure will be described in more detail below with reference to the figures. Although the figures show some embodiments of the present disclosure, it should be understood that the present disclosure may be implemented in many forms and should not be understood as being limited to the embodiments shown herein. On the contrary, these embodiments are provided herein to enable a more complete and complete understanding of the present disclosure. It should be understood that the figures and embodiments of the present disclosure are used for illustration purposes only and are not used to limit the scope of protection of the present disclosure.

[0010]

[0015] As used herein, the term "includes" and variations thereof should be read as open terms meaning "includes, but is not limited to." The term "based on" should be read as "based at least in part on." The term "in one embodiment" should be read as "based at least in part on." The term "another embodiment" should be read as "at least one other embodiment." The term "some embodiments" should be read as "at least some embodiments." Definitions of other terms are provided in the text below.

[0011]

[0016] Generally, memory consumes a large portion of the hardware cost of a computing device such as a computer or a server. For example, DRAM can consume up to 40% or even higher hardware cost of a cloud server, therefore memory compression may be used to reduce memory costs or further scale up the server. Memory compression techniques mainly include software-based memory compression and hardware-based memory compression. Software-based memory compression is implemented through software and consumes a lot of processor resources, leading to excessive latency, which causes significant slowdown of the operating system and / or application. Traditional hardware-based memory compression suffers from high metadata overhead. Conventional methods of memory compression have poor data layout and poor block allocation mechanisms that cause head and internal fragmentation, leading to low utilization of compressed memory. Therefore, conventional methods of memory compression can cause system slowdown or high metadata overhead.

[0012]

[0017] To this end, a new approach for hardware-based memory compression has been proposed. In an embodiment of the present disclosure, a compressed memory is divided into multiple segments, each segment is divided into multiple subsegments, and each subsegment in the uncompressed data space is compressed into a block in the compressed data space. When a read request to a subsegment in a segment in the compressed memory is received, a corresponding entry is first determined based on a first-level address mapping between the subsegment and the entry, and then a corresponding block is determined based on a second-level address mapping between the entry and the block.

[0013]

[0018] According to embodiments of the present disclosure, the use of two-level address mapping reduces the size of entries, thereby achieving low metadata overhead. Moreover, the proposed data layout for compressed memory according to embodiments of the present disclosure can enable consistently fast block allocation within the compressed memory. Furthermore, because embodiments of the present disclosure use hardware-based memory compression, system and application slowdowns can be avoided compared to software-based memory compression.

[0014]

[0019] Furthermore, in some embodiments of the present disclosure, the compression ratio of memory compression can be increased by expanding the size of each subsegment (which is the compression unit of compressed memory), thereby further improving memory utilization. Embodiments of the present disclosure can configure multiple pointers within each entry, which can reduce the memory storage unit (which is the block size), thereby reducing internal fragmentation. Other advantages of embodiments of the present disclosure will be described below with reference to exemplary implementations. Reference will be made below to FIGS. 1 to 8 to illustrate the basic principles and some exemplary embodiments of the present disclosure herein.

[0015]

[0020] 1 shows a block diagram of a computing device / server 100 in which one or more embodiments of the present disclosure may be implemented. It will be understood that the computing device / server 100 depicted in FIG. 1 is merely illustrative and does not limit in any way the functionality and scope of embodiments of the present disclosure. The computing device / server 100 may be a computer or a server.

[0016]

[0021] 1, computing device / server 100 is in the form of a general-purpose computing device. Components of computing device / server 100 may include, but are not limited to, one or more processors or processing units 110, memory 120, storage device 130, one or more communication units 140, one or more input devices 150, and one or more output devices 160. Processing unit 110 may be a physical or virtual processor and may perform various processes based on programs stored in memory 120. In a multiprocessor system, multiple processing units may execute computer-executable instructions in parallel to improve the concurrent processing capabilities of computing device / server 100.

[0017]

[0022] The computing device / server 100 typically includes a variety of computer storage media, including both volatile and non-volatile storage media. The memory 120 may be any medium accessible by the computing device / server 100, including, but not limited to, volatile media, or removable and non-removable media. The memory 120 may be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or any combination thereof.

[0018]

[0023] 1, memory 120 may include a program 125 for implementing memory compression and block allocation according to embodiments of the present disclosure, which may have one or more sets of program modules configured to perform the methods and functions of various embodiments described herein. In some embodiments, memory 120 may include conventional regular memory (e.g., uncompressed memory) and the proposed compressed memory according to embodiments of the present disclosure, where the compressed memory may have a novel data layout and block allocation mechanism and may be used to store compressed data that may be accessed rarely or infrequently.

[0019]

[0024] Storage device 130 can be any removable or non-removable media, including machine-readable media such as flash drives, disks, and any other media, used to store information and / or data and can be accessed within computing device / server 100. For example, storage device 130 can be a hard disk drive (HDD) or a solid-state drive (SSD).

[0020]

[0025] Computing device / server 100 may further include additional removable / non-removable or volatile / non-volatile storage media. Although not shown in Figure 1, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk. In such cases, each drive is connected to a bus (not shown) via one or more data media interfaces.

[0021]

[0026] The communications unit 140 communicates with other computing devices via a communications medium. Additionally, the functionality of the components of the computing device / server 100 may be implemented in a single computing cluster or multiple computing machines that communicate with each other via communications connections. Thus, the computing device / server 100 may operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or other network nodes.

[0022]

[0027] Input device(s) 150 may include one or more input devices such as a mouse, keyboard, trackball, etc. Output device(s) 160 may include one or more output devices such as a display, loudspeaker, printer, etc. Computing device / server 100 may further communicate via communication unit 140 with one or more external devices (not shown), such as a storage device or a display device, one or more devices that allow a user to interact with computing device / server 100, or any device that allows computing device / server 100 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication is performed via an input / output (I / O) interface (not shown). Reference is now made below to Figures 2-8 to specifically illustrate example embodiments of the present disclosure.

[0023]

[0028] FIG. 2 illustrates an exemplary architecture 200 using tile-based compressed memory according to an embodiment of the present disclosure. As shown in FIG. 2, architecture 200 includes a CPU 210, a memory controller 220, an uncompressed memory 231, a compressed memory 232, and a software application 240. CPU 210 may be a processing unit for executing program instructions, such as processing unit 110 shown in FIG. 1. Memory controller 220 is a digital circuit that manages the flow of data between uncompressed memory 231 and compressed memory 232. The memory controller may be a separate chip or may be integrated into another chip (located on the same die or as an integrated part of CPU 210). The memory controller can keep the memory active by supplying current to the memory while also managing read and write operations in the memory.

[0024]

[0029] Uncompressed memory 231 is a conventional memory, such as a conventional DRAM, that may be used to store frequently accessed data because frequently accessed data is frequently accessed and not suitable for compression. Compressed memory 232 is a newly proposed memory according to an embodiment of the present disclosure that may be used to store less frequently accessed data to increase the amount of data that can be stored in memory. Software application 240 includes one or more programs, which may include applications, libraries, drivers, an operating system, a hypervisor, and / or other components. One or more programs in software application 240 can distinguish between frequently accessed data and infrequently accessed data and control which data should be stored in uncompressed memory 231 and which data should be stored in compressed memory 232. In an embodiment of the present disclosure, uncompressed memory 231 and compressed memory 232 can share the same address space accessible to CPU 210.

[0025]

[0030] In some embodiments, data compression and decompression operations may be implemented in compressed memory 232, in which case embodiments of the present disclosure may be implemented as a new design for data layout and block allocation within a memory module. Alternatively, compression and decompression operations for compressed memory 232 may be implemented in memory controller 220.

[0026]

[0031] According to the example architecture 200, the CPU 210 can send data to uncompressed memory 231 or compressed memory 232 via the memory controller 220 based on the determination of the software application 240. Embodiments of the present disclosure propose a new data layout and block allocation algorithm for the compressed memory 232, which can reduce the metadata overhead of the compressed memory and achieve fast block allocation in the compressed memory.

[0027]

[0032] 3 illustrates a flowchart of a method 300 for hardware-based memory compression according to an embodiment of the present disclosure. It should be understood that the method 300 may be performed by the memory 120 of the computing device / server 100 as described with reference to FIG. 1, or by the compression memory 232 or memory controller 220 as described with reference to FIG. 2.

[0028]

[0033] At 302, a read request to a memory is received, the read request being for a sub-segment of a segment in the memory. In this embodiment, the compressed memory is divided into multiple segments, each of which may have a first predetermined size (e.g., 32 KiB), and may be called a "tile." For example, the memory may have a capacity of 4 GiB. Assume that the compression ratio of the compressed memory is 2:1, and 4 GiB of compressed memory can store 8 GiB of uncompressed data.

[0029]

[0034] In embodiments of the present disclosure herein, each segment is divided into multiple subsegments, each of which may have a second predetermined size (e.g., 512 bytes) and may be referred to as a "paragraph." Each subsegment in the uncompressed data space is compressed into a block in the compressed data space, each of which may have a third predetermined size (e.g., 64 bytes). While illustrative sizes of memory, tiles, paragraphs, and blocks are described in some embodiments, it should be understood that other sizes may be possible depending on manual configuration by a developer and / or administrator. A tile is a fixed-size, self-contained data structure consisting of a root entry, a block, and a bitmap. While embodiments of the present disclosure use the terms "tile" and "paragraph" to represent the concepts "segment" and "subsegment," it should be understood that other terms or words may be possible to express the concepts "segment" and "subsegment."

[0030]

[0035] At 304, an entry within the segment corresponding to the subsegment is determined, where the entry includes an index (e.g., one or more pointers). In some embodiments of the present disclosure, the entry may be within the root of the tile as part of the tile's self-contained data structure, and the entry may be referred to as a "root entry." For example, the corresponding root entry is first determined based on a first-level address mapping between paragraphs and entries. In some embodiments, the first-level address mapping may be a fixed mapping rule, where the mapping rule may include a static mapping between paragraphs within the tile and root entries. The corresponding root entry may be within a particular tile that will be accessed once the paragraph is known. In this manner, the storage overhead of the root entry can be reduced as opposed to dynamic mapping. In some embodiments, the fixed mapping rule may be configured in an interleaved manner. For example, the last bit of a paragraph address is used as an index to the root entry so that consecutive paragraphs are widely distributed. In this manner, overflow events within the tile can be reduced or better handled. Alternatively, the fixed mapping rule may be a linear mapping (eg, consecutive paragraphs have similar compression budgets), or a random mapping (such as a CRC32 algorithm).

[0031]

[0036] At 306, one or more blocks for storing compressed data associated with the read request are determined based on an index in the entry. For example, the corresponding block is determined based on a second-level address mapping between the root entry and the block. The second-level address mapping may be a dynamic mapping rule that provides dynamic mapping between the root entry and the block. In this manner, fast block allocation can be achieved. According to the method 300 of the present disclosure, the use of two-level address mapping reduces the size of the entry, thereby achieving low metadata overhead and saving memory space. Furthermore, because compressed memory can store more data than uncompressed memory due to compression, embodiments of the present disclosure can reduce memory costs and / or scale up memory capacity.

[0032]

[0037] In some embodiments, if the determined root entry contains two or more pointers, two or more corresponding blocks may be determined and compressed data may be read from two or more blocks in parallel. In this manner, data blocks may be fetched in parallel. This can increase the read speed of compressed memory: after reading the root entry, the second level blocks can be determined and multiple block reads can be issued in parallel to reduce latency.

[0033]

[0038] Moreover, because one root entry may contain multiple pointers, multiple blocks can be determined from one entry. That is, one paragraph can be compressed into many blocks (e.g., one block, two blocks, four blocks, eight blocks, etc.). In this way, by allowing a paragraph size larger than the block size, multiple blocks may be configured to store compressed data compressed from one paragraph, thus reducing internal fragmentation.

[0034]

[0039] 4 shows a schematic diagram 400 of two-level address mapping of tiles, according to an embodiment of the present disclosure. As shown in FIG. 4, a compressed memory includes multiple tiles, such as tiles 410, 420, and paragraph-to-block address mapping within a tile is implemented through two-level address mapping, in which a root entry is used as indirection for the two-level address mapping.

[0035]

[0040] Referring to FIG. 4 , a tile 410 may include multiple root entries (e.g., root entry 411), multiple blocks (e.g., blocks 412 and 413), and a bitmap (e.g., bitmap 414), where the root entry is used to search for corresponding blocks, the blocks are used to store compressed data, and the bitmap is used to indicate the allocation status of blocks within the tile 410. For example, each bit in bitmap 414 may indicate whether each block within the tile 410 is allocated. In the example of FIG. 4 , first, one paragraph within the tile is mapped to a root entry (e.g., root entry 411) based on a fixed mapping, as indicated by arrow 416, where each paragraph corresponds to one root entry, and root entry 411 includes one or more pointers for finding the corresponding block. Second, root entry 411 is mapped to blocks 412 and 413 based on a dynamic mapping, as indicated by arrows 417 and 418. By limiting dynamic mapping to tiles, allocation of blocks in compressed memory can be made stable and fast.

[0036]

[0041] In some embodiments, the maximum number of pointers in the root entry 411 may be determined based on a first ratio between the paragraph size and the block size, while the size of each pointer in the root entry 411 may be determined based on a second ratio between the tile size and the block size. For example, in the above example where each tile has a size of 32 KiB, each paragraph has a size of 512 bytes, and each block has a size of 64 bytes, the size of each root entry is 8 x 9 bits, or 9 bytes, where 8 represents the maximum number of pointers in one root entry and 9 bits represents the size of each pointer. In this way, the root entry, i.e., metadata, according to embodiments of the present disclosure occupies only a small portion of memory space, thereby saving metadata overhead in compressed memory.

[0037]

[0042] 5 shows a schematic diagram 500 of an example data compression from a paragraph to one or more blocks according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the unit of memory allocation is a tile of size, such as 32 KiB, the unit of compression in the uncompressed data space is a paragraph of size, such as 512 bytes, and the unit of memory access in the compressed data space is a block of size, such as 64 bytes. In the example, the size of one paragraph is preset to be, for example, eight times the size of one block. In this way, by increasing the size of each paragraph, the compression ratio of memory compression can be increased, since larger compression units generally have a larger compression ratio than smaller compression units.

[0038]

[0043] 5, each tile may be divided into multiple paragraphs, such as paragraphs 510 and 520, where a paragraph may be a data object seen by a processor and an application. As shown in FIG. 5, paragraph 510 in the uncompressed data space may be compressed into four blocks in the compressed data space, such as blocks 511, 512, 513, and 514, while paragraph 520 in the uncompressed data space may be compressed into three blocks in the compressed data space, such as blocks 521, 522, and 523. As shown in FIG. 5, different data may have different compression ratios depending on the type of data and the actual content of the data. In other words, the actual amount of blocks depends on the compression ratio of the individual paragraphs.

[0039]

[0044] 6 illustrates an example data layout 600 within a tile 610, in accordance with an embodiment of the present disclosure. As illustrated, the tile 610 includes multiple root entries 620 (such as root entries 621 and 622), multiple data blocks 630, and a bitmap 640. In the example data layout 600, the tile 610 may have a size of, for example, 32 KiB, with each paragraph having a size of 512 bytes and each block having a size of 64 bytes.

[0040]

[0045] In the above example, tile 610 has a total of 512 blocks. Assume the compression ratio is preset to 2:1, allowing tile 610 to have 128 paragraphs and 128 root entries. Each root entry can contain up to eight pointers, each 9 bits in size. Thus, each paragraph can correspond to one root entry, which can be up to 9 bytes in size. The 128 paragraphs occupy 128 x 9 bytes (corresponding to 18 blocks) of memory space, and each paragraph can be compressed to 8 blocks. Bitmap 640 is used to control the allocation of blocks in compressed memory, and the 512 blocks in tile 610 require 512 bits per block. Thus, tile 610 has 18 blocks for storing root entries and 1 block for storing the bitmap. The tile 610 as a whole occupies 19 blocks for storing metadata, leaving 493 blocks remaining for storing compressed data, such as the blocks with IDs "18" through "510" in FIG. 6. In this way, memory utilization can be improved.

[0041]

[0046] 6, bitmap 640 indicates that some blocks are allocated while others are not, with a bit "1" representing that the corresponding block is allocated. When a write request to tile 610 is received, bitmap 640 will first be checked to allocate one or more blocks for storing compressed data, and then the corresponding root entry will be written with the IDs of the allocated blocks, and bitmap 640 will also be modified. When a read request to a paragraph in tile 610 is received, the corresponding root entry (e.g., root entry 621) will first be determined based on the first-level fixed mapping, and then the associated blocks (e.g., blocks with IDs "18," "19," "20," and "21") will be determined based on the second-level dynamic mapping. In this way, blocks can be allocated and identified in a fast manner, thereby improving the storage efficiency of the compressed memory.

[0042]

[0047] 7 illustrates a flowchart of a method 700 for writing compressed data according to an embodiment of the present disclosure. In comparison to processing a read request to a tile, such as method 300 of FIG. 3, method 700 represents a method for processing a write request to memory. It should be understood that method 700 may be performed by memory 120 of computing device / server 100, such as described with reference to FIG. 1, or by compressed memory 232 or memory controller 220, such as described with reference to FIG. 2.

[0043]

[0048] At 702, when a write request to a memory in compressed memory is received, a tile-to-root-entry address translation is performed. For example, the address translator can calculate a root entry address in compressed memory space from a physical address in uncompressed memory space.

[0044]

[0049] At 704, a bitmap for the tile is checked, with each bit in the bitmap indicating whether each block in the tile is allocated. At 706, it is determined whether enough blocks are available in the tile for the write request according to the bitmap. If the bitmap indicates that enough blocks are available in the tile for the write request, at 708, compressed data associated with the write request is written to one or more blocks in the tile based on the bitmap. Then, at 710, the bitmap and root entry are similarly written or updated, and the compressed data is successfully stored in compressed memory.

[0045]

[0050] If the bitmap indicates that not enough blocks are available in the tile for the write request, another tile in memory that has enough available blocks for the write request must be found at 708. In this case, this means that the blocks in this tile have been utilized and an overflow event has occurred. At least a portion of the compressed data associated with the write request is then written to a block in another tile at 714. In this way, the overflow event can be handled correctly to avoid data loss in the compressed memory. In some embodiments, a special value (e.g., 511) in a normal root entry may be used to represent an overflow root entry, and the special value is followed by a pointer that references another block in the overflow tile. A block in the overflow tile may be used as the root entry to reference a compressed data block in the overflow tile. In some embodiments, another special value (e.g., 0) may be used to indicate an empty root entry, which means that no paragraphs have been allocated or that all bits of the memory contents are zero.

[0046]

[0051] FIG. 8 illustrates an example hardware architecture 800 for implementing memory compression according to embodiments of the present disclosure. While FIG. 8 illustrates an example of the present disclosure that may be implemented in a memory controller, embodiments of the present disclosure may also be implemented in compressed memory. The example hardware architecture 800 may be a field programmable gate array (FPGA) board that attaches to a host via a Peripheral Component Interconnect Express (PCIe) bus. The hypervisor maps the FPGA's PCIe memory-mapped I / O (MMIO) space to software, so the CPU can directly access the compressed memory. Additionally, the CPU can directly access uncompressed memory as well.

[0047]

[0052] As shown in FIG. 8, the example hardware architecture 800 includes a platform wrapper 810, a PCIe / UPI 820, a memory controller (including a cache / buffer 831, a write controller 832, and a read controller 833), The memory controller 830 may control data passing to and from the DRAM 840 and may communicate with a platform wrapper 810 via PCIe / UPI 820. The wrapper 810 may be used to read the root entry and compressed data in a block during a read request, and the wrapper 810 may be used to read the bitmap during a write request.

[0048]

[0053] The cache / buffer 831 stores paragraphs that are being read / written or recently accessed and can have two purposes. First, the cache / buffer 831 finds conflicting read / write operations on the same paragraph and queues them in a per-paragraph FIFO so that the operations can be performed sequentially. The cache / buffer 831 only issues independent read / write operations to the rest of the memory controller 830, thus avoiding inconsistencies caused by simultaneous operations. Second, the cache / buffer 831 caches recently accessed paragraphs to alleviate the access bloat problem. Because the CPU access granularity (cache line size or instruction word size) is typically smaller than the paragraph size, the CPU will issue multiple read / write operations when sequentially scanning a paragraph. By using a cache, compressed blocks of a paragraph do not need to be loaded and decompressed from DRAM multiple times, thereby reducing overhead.

[0049]

[0054] The read controller 833 receives a read request from the cache / buffer 831 and calculates a root entry address in the compressed memory space from the address in the read request. The read controller 833 then accesses the root entry, determines the block offset within the tile, and calculates the block address in the compressed memory space. The read controller 833 then accesses the block and sends the data to the decompression engine, and the decompressed data is stored in the cache / buffer 831 and sent to the CPU.

[0050]

[0055] The write controller 832 receives a write request from the cache / buffer 831 and calculates a root entry address in the compressed memory space from the address in the write request. The write controller 832 then accesses the root entry and bitmap to determine the block offset within the tile and calculates the block address in the compressed memory space. The write controller 832 modifies the data according to the write request and then sends the data to the compression engine. After compression, one or more blocks are allocated or deallocated from the block allocator depending on the change in the compressed data size. Finally, the compressed data is written to the blocks within the tile.

[0051]

[0056] The compression engine can perform data compression and decompression. To speed up concurrent requests, the write controller 832 can have multiple compression engines running in parallel internally. According to an embodiment of the present disclosure, the order of concurrent requests is not important because the cache / buffer 831 filters conflicting operations.

[0052]

[0057] The block allocator can manage the bitmaps in each tile. To speed up allocation, the block allocator maintains a bitmap cache internally to cache the bitmaps of recently accessed tiles and some tiles that have many available blocks. To cancel allocation, the corresponding bit may be set to zero. For allocation, the block allocator first loads the bitmap of the corresponding tile. If there are not enough available blocks, If there is, the corresponding bit is set. If not, the block allocator checks the bitmap cache to find an overflow tile with enough available blocks. If it cannot find such a tile, it scans the bitmap in several tiles and reports an allocation failure if it cannot find an overflow tile.

[0053]

[0058] Functionality described herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), etc.

[0054]

[0059] Program codes for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device such that, when executed by the processor or controller, the program codes implement the functions / acts specified in the flowcharts and / or block diagrams. The program code may be executed entirely on the machine as a stand-alone software package, partially on the machine, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0055]

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

[0056]

[0061] Furthermore, while acts are depicted in a particular order, this should not be construed as requiring such acts to be performed in the particular order or sequence shown, or that all of the depicted acts be performed, to achieve desirable results. In some situations, multitasking and simultaneous processing may be advantageous. Similarly, while details of several specific implementations are included in the above discussion, these should not be construed as limiting the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Some features that are described in the context of separate embodiments may also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation may be implemented in multiple embodiments separately or in any suitable subcombination.

[0057]

[0062] Some example embodiments of the present disclosure are listed below.

[0063] In one aspect, a method for memory compression is provided, the method comprising receiving a read request to a memory, the memory being divided into a plurality of segments and a plurality of the segment is divided into a plurality of subsegments, one of the plurality of subsegments is compressed into one or more blocks, and the read request is for the subsegment of the segment in memory; determining an entry in the segment corresponding to the subsegment, the entry including an index; and determining a block that stores compressed data associated with the read request based on the index in the entry.

[0058]

[0064] In some embodiments, determining an entry within the segment that corresponds to the sub-segment includes determining an entry that corresponds to the sub-segment based on a mapping rule, wherein the mapping rule includes a static mapping within the segment between the sub-segment and the entry.

[0059]

[0065] In some embodiments, the size of one sub-segment is preset to be at least eight times the size of one block.

[0066] In some embodiments, determining a block to store compressed data associated with the read request based on an index in the entry includes determining two or more blocks associated with the read request based on two or more pointers in the entry, wherein a maximum number of pointers in the entry is determined based on a first ratio between the size of one subsegment and the size of one block, and the size of one pointer in the entry is determined based on a second ratio between the size of one segment and the size of one block.

[0060]

[0067] In some embodiments, the method may further include, in response to determining the two or more blocks associated with the read request, reading compressed data from the two or more blocks in parallel, and decompressing the compressed data to generate decompressed data.

[0061]

[0068] In some embodiments, the method may further include receiving a write request to the memory; and in response to receiving the write request, checking a bitmap in the segment, the segment including a plurality of entries, a plurality of blocks, and a bitmap, each bit in the bitmap indicating whether each block in the segment is allocated; and in response to the bitmap indicating that sufficient blocks are available in the segment for the write request, writing compressed data associated with the write request to one or more blocks in the segment based on the bitmap; and updating the bitmap and the one or more entries in the segment.

[0062]

[0069] In some embodiments, the method may further include, in response to the bitmap indicating that sufficient blocks are not available in the segment for the write request, determining a further segment in the memory having sufficient available blocks, and writing at least a portion of the compressed data associated with the write request to a block in the further segment.

[0063]

[0070] In some embodiments, infrequently accessed data is migrated to compressed memory while frequently accessed data is migrated to uncompressed memory, with the uncompressed and compressed memory sharing the same address space accessible to the processor.

[0064]

[0071] In some embodiments, the method is implemented in a memory, and a read request to a subsegment of a segment in the memory is received via a memory controller.

[0065]

[0072] In another aspect, a memory is provided comprising a memory chip and a controller configured to perform acts including receiving a read request to the memory, where the memory is divided into a plurality of segments, one of the plurality of segments is divided into a plurality of sub-segments, one of the plurality of sub-segments is compressed into one or more blocks, and the read request is for a sub-segment of the segment in the memory; determining an entry within the segment corresponding to the sub-segment, the entry including an index; and determining a block to store compressed data associated with the read request based on the index in the entry.

[0066]

[0073] In some embodiments, determining the entry in the segment that corresponds to the subsegment includes determining the entry that corresponds to the subsegment based on a mapping rule, where the mapping rule includes a static mapping within the segment between the subsegment and the entry.

[0067]

[0074] In some embodiments, the size of one sub-segment is preset to be at least eight times the size of one block.

[0075] In some embodiments, determining a block to store compressed data associated with the read request based on an index in the entry includes determining two or more blocks associated with the read request based on two or more pointers in the entry, wherein a maximum number of pointers in the entry is determined based on a first ratio between the size of one subsegment and the size of one block, and the size of one pointer in the entry is determined based on a second ratio between the size of one segment and the size of one block.

[0068]

[0076] In some embodiments, the acts may further include, in response to determining the two or more blocks associated with the read request, reading compressed data from the two or more blocks in parallel and decompressing the compressed data to generate decompressed data.

[0069]

[0077] In some embodiments, the acts may further include receiving a write request to the memory; in response to receiving the write request, checking a bitmap in a segment, the segment including a plurality of entries, a plurality of blocks, and a bitmap, each bit in the bitmap indicating whether each block in the segment is allocated; and in response to the bitmap indicating that sufficient blocks are available in the segment for the write request, writing compressed data associated with the write request to one or more blocks in the segment based on the bitmap; and updating the bitmap and one or more entries in the segment.

[0070]

[0078] In some embodiments, the actions may further include, in response to the bitmap indicating that sufficient blocks are not available in the segment for the write request, determining a further segment in the memory that has sufficient available blocks, and writing at least a portion of the compressed data associated with the write request to a block in the further segment.

[0071]

[0079] In some embodiments, infrequently accessed data is migrated to compressed memory while frequently accessed data is migrated to uncompressed memory, with the uncompressed and compressed memory sharing the same address space accessible to the processor.

[0072]

[0080] In a further aspect, a program product is provided that includes executable instructions that, when executed on a device, cause the device to perform acts including receiving a read request to a memory, where the memory is divided into a plurality of segments, one of the plurality of segments is divided into a plurality of subsegments, one of the plurality of subsegments is compressed into one or more blocks, and the read request is for a subsegment of the segment in the memory; determining an entry within the segment that corresponds to the subsegment, the entry including an index; and determining, based on the index in the entry, a block that stores compressed data associated with the read request.

[0073]

[0081] In some embodiments, determining an entry within the segment that corresponds to the sub-segment includes determining an entry that corresponds to the sub-segment based on a mapping rule, wherein the mapping rule includes a static mapping within the segment between the sub-segment and the entry.

[0074]

[0082] In some embodiments, the size of one sub-segment is preset to be at least eight times the size of one block.

[0083] In some embodiments, determining a block to store compressed data associated with the read request based on an index in the entry includes determining two or more blocks associated with the read request based on two or more pointers in the entry, wherein a maximum number of pointers in the entry is determined based on a first ratio between the size of one subsegment and the size of one block, and the size of one pointer in the entry is determined based on a second ratio between the size of one segment and the size of one block.

[0075]

[0084] In some embodiments, the acts may further include, in response to determining the two or more blocks associated with the read request, reading compressed data from the two or more blocks in parallel and decompressing the compressed data to generate decompressed data.

[0076]

[0085] In some embodiments, the acts may further include receiving a write request to the memory; in response to receiving the write request, checking a bitmap in a segment, the segment including a plurality of entries, a plurality of blocks, and a bitmap, each bit in the bitmap indicating whether each block in the segment is allocated; and in response to the bitmap indicating that sufficient blocks are available in the segment for the write request, writing compressed data associated with the write request to one or more blocks in the segment based on the bitmap; and updating the bitmap and one or more entries in the segment.

[0077]

[0086] In some embodiments, the actions may further include, in response to the bitmap indicating that sufficient blocks are not available in the segment for the write request, determining a further segment in the memory that has sufficient available blocks, and writing at least a portion of the compressed data associated with the write request to a block in the further segment.

[0078]

[0087] In some embodiments, infrequently accessed data is migrated to compressed memory while frequently accessed data is migrated to uncompressed memory, with the uncompressed and compressed memory sharing the same address space accessible to the processor.

[0079]

[0088] Although the present disclosure has been described in language specific to structural features and / or method acts, it will be understood that the subject matter specified in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0080]

[0089] The description of various embodiments of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

Claims

1. 1. A method for managing compressed memory in a computing device, comprising: receiving, by a memory controller, a request associated with a memory operation in a compressed memory, the compressed memory being organized into a plurality of tiles, each tile having a plurality of root entries and a corresponding bitmap indicating an allocation status of data blocks within the tile; identifying, by the memory controller, a root entry corresponding to a tile of the plurality of tiles based on static mapping rules, the root entry including a plurality of pointers to the data block; determining, by the memory controller, a state of the data block associated with the root entry by referencing the bitmap; In response to the request being a write operation and the bitmap indicating the availability of sufficient unallocated data blocks within the tile, allocating one or more of the unallocated data blocks to store data associated with the write operation, updating the bitmap to reflect the allocation, and updating the root entry with a pointer to the data block allocated by the allocation; A method comprising:

2. 2. The method of claim 1, further comprising, in response to the request being a write operation and the bitmap indicating insufficient unallocated data blocks in the tile, identifying an overflow tile having sufficient unallocated data blocks, allocating one or more of the unallocated data blocks to the overflow tile, updating the bitmap of the overflow tile to reflect the allocation, and generating an overflow entry in an original tile that points to the data blocks in the overflow tile allocated by the allocation.

3. 2. The method of claim 1, further comprising, in response to the request being a read operation, retrieving compressed data from the data block indicated by the root entry, and decompressing the compressed data to reconstruct the tile.

4. 4. The method of claim 3, wherein the decompression of the compressed data includes utilizing a hardware-based decompression engine integrated within the memory controller, the hardware-based decompression engine configured to decompress multiple data blocks in parallel to facilitate data reconstruction.

5. 2. The method of claim 1, wherein the static mapping rule includes reducing metadata overhead associated with address translation by using a portion of the tile's address as an index to directly locate the corresponding root entry within the tile.

6. 6. The method of claim 5, wherein the static mapping rules employ an interleaved distribution of the root entries within the tile to balance load across the data blocks and minimize the likelihood of overflow events.

7. 2. The method of claim 1, further comprising setting the plurality of pointers within each root entry to reduce internal fragmentation within the tile.

8. 2. The method of claim 1, wherein the plurality of pointers in the root entry are configured to support a two-level address mapping scheme, where a first level address mapping determines a root entry within the tile, and a second level address mapping determines a particular data block for each of the plurality of pointers within the tile based on the plurality of pointers in the root entry.

9. 2. The method of claim 1, wherein the bitmap is further utilized to identify a set of contiguous, unallocated data blocks within the tile to accommodate the write operation, thereby reducing latency associated with accessing non-contiguous data blocks.

10. A memory device for managing compressed data, comprising: a plurality of memory tiles, each tile comprising a plurality of root entries and a corresponding bitmap indicating the allocation status of data blocks within said tile; 1. A hardware memory controller, comprising: receiving a request associated with a memory operation for a data segment in compressed memory; identifying a root entry corresponding to the data segment based on a static mapping rule, the root entry including a plurality of pointers to the data block; determining a state of the data block associated with the root entry by referencing the bitmap; In response to the request being a write operation and the bitmap indicating the availability of sufficient unallocated data blocks, allocate one or more unallocated data blocks within the tile to store data associated with the write operation, update the bitmap to reflect the allocation, and update the root entry with a pointer to the data block allocated by the allocation; In response to the request being a read operation, obtaining compressed data from the data block indicated by the root entry and decompressing the compressed data to reconstruct the data segment; a hardware memory controller configured to: A memory device comprising:

11. 11. The memory device of claim 10, wherein the hardware memory controller is further configured to reduce metadata overhead associated with address translation by using a portion of an address of the data segment as an index to directly locate the corresponding root entry within the tile based on the static mapping rule.

12. 11. The memory device of claim 10, wherein the hardware memory controller is further configured, in response to the bitmap indicating insufficient unallocated data blocks within the tile for write operations, to trigger a compaction process to consolidate fragmented data blocks within the tile, thereby freeing up additional data blocks for allocation and reducing internal fragmentation within the compressed memory.

13. 13. The memory device of claim 12, wherein the static mapping rules employed by the hardware memory controller utilize an interleaved distribution of the data segments to multiple root entries within the tile to balance load across the data blocks and minimize the likelihood of overflow events.

14. The hardware memory controller further, in response to the request being a write operation and the bitmap indicating insufficient unallocated data blocks within the tile, Identifying overflow tiles that have sufficient unallocated data blocks; allocating one or more of the unallocated data blocks to the overflow tile; updating the bitmap of the overflow tile to reflect the allocation; creating an overflow entry in the original tile that points to the data block allocated by the allocation in the overflow tile; The memory device of claim 11 configured to:

15. 1. A program product comprising executable instructions stored on a non-transitory computer-readable medium, the executable instructions, when executed by a processor of a memory device, Dividing a memory into a plurality of tiles, each tile comprising a plurality of root entries and a corresponding bitmap indicating the allocation status of data blocks within the tile; receiving a request associated with a memory operation for a data segment in compressed memory; identifying a root entry corresponding to the data segment based on a static mapping rule, the root entry including a plurality of pointers to the data block; determining a state of the data block associated with the root entry by referencing the bitmap; In response to the request being a write operation and the bitmap indicating the availability of sufficient unallocated data blocks, allocate one or more unallocated data blocks within the tile to store data associated with the write operation, update the bitmap to reflect the allocation, and update the root entry with a pointer to the data block allocated by the allocation; In response to the request being a read operation, obtaining compressed data from the data block indicated by the root entry and decompressing the compressed data to reconstruct the data segment; and in response to the request being a write operation and the bitmap indicating insufficient unallocated data blocks in the tile, identifying an overflow tile having sufficient unallocated data blocks, allocating one or more of the unallocated data blocks to the overflow tile, updating the bitmap of the overflow tile to reflect the allocation, and creating an overflow entry in the original tile that points to the data block in the overflow tile allocated by the allocation. activating the memory device to Program products.

Images