Hardware-based memory compression

Abstract

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 for a subsegment in a segment in the compressed memory is received, the corresponding entry is first determined based on a first-level address mapping between the subsegment and the entry, and then the corresponding block is determined based on a second-level address mapping between the entry and the block. By using a two-level address mapping, the size of the entry can be reduced, thereby achieving lower metadata overhead. In addition, a data layout for the compressed memory is proposed.

Description

Background Art

[0001] Memory refers to a component in a computing device that stores information for immediate use within the computing system, and is also referred to as main memory. Memories such as random access memory (RAM) operate at high speeds, unlike storage devices that provide slower access to information but offer 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) and static random access memory (SRAM).

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

[0003] In an embodiment of the present disclosure, a method for hardware-based memory compression is provided. According to an embodiment of the present disclosure, the compressed memory is divided into a plurality of segments, each segment is divided into a plurality of sub-segments, and each sub-segment in the uncompressed data space is compressed into one or more blocks in the data space. When a read request for a sub-segment in a segment in the compressed memory is received, the corresponding entry is first determined based on the first-level address mapping between the sub-segment and the entry, and then the one or more corresponding blocks are determined based on the second-level address mapping between the entry and the one or more blocks. According to an embodiment of the present disclosure, by using two-level address mapping, the size of the entry can be reduced, thereby achieving lower metadata overhead. In addition, the data layout of the proposed compressed memory can achieve stable and fast block allocation in the compressed memory.

[0004] 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. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0006] Figure 1 A block diagram illustrating a computing device / server in which one or more embodiments of the present disclosure may be implemented;

[0007] Figure 2 An example architecture with tile-based compressed memory according to an embodiment of the present disclosure is shown;

[0008] Figure 3 A flowchart of a method for hardware-based memory compression according to an embodiment of the present disclosure is shown;

[0009] Figure 4 A schematic diagram illustrating two-level address mapping for tiles according to an embodiment of the present disclosure is shown;

[0010] Figure 5 A schematic diagram illustrating example data compression from paragraphs to one or more blocks according to an embodiment of the present disclosure is shown;

[0011] Figure 6 shows an example data layout in a tile according to an embodiment of the present disclosure;

[0012] Figure 7 A flowchart illustrating a method for writing compressed data to a tile according to an embodiment of the present disclosure is shown; and

[0013] Figure 8 An example hardware architecture for implementing memory compression according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0014] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the accompanying drawings illustrate some embodiments of the present disclosure, it should be understood that the present disclosure can be implemented in various forms, and the present disclosure should not be construed as being limited to the embodiments shown herein. On the contrary, these embodiments are provided herein to enable a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

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

[0016] Typically, memory consumes most of the hardware cost of a computing device such as a computer or server. For example, DRAM may consume up to 40% or even more of the hardware cost of a cloud server, and therefore memory compression can be used to reduce memory costs or further scale out servers. Memory compression technologies 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 and causes excessive latency, causing the operating system and / or applications to significantly slow down. Traditional hardware-based memory compression has poor data layout and block allocation mechanisms, resulting in high metadata overhead and internal fragmentation, resulting in low compressed memory utilization. Therefore, traditional memory compression methods may cause system slowdowns or high metadata overhead.

[0017] To this end, a new method for hardware-based memory compression is 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 one or more blocks in the data space. When a read request for a subsegment in a segment in the compressed memory is received, the corresponding entry is first determined based on the first-level address mapping between the subsegment and the entry, and then the one or more corresponding blocks are determined based on the second-level address mapping between the entry and the one or more blocks.

[0018] According to embodiments of the present disclosure, by using a two-level address mapping, the size of entries can be reduced, thereby achieving lower metadata overhead. Furthermore, the data layout for compressed memory proposed according to embodiments of the present disclosure enables stable and fast block allocation in 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.

[0019] In addition, in some embodiments of the present disclosure, by increasing the size of each sub-segment (which is a compression unit in the compressed memory), the compression rate of the memory compression can be improved, thereby further improving the utilization of the memory. The embodiments of the present disclosure can configure multiple pointers in each entry, which can reduce the storage unit of the memory (i.e., block size), thereby reducing internal fragmentation. Other advantages of the embodiments of the present disclosure will be described below with reference to examples. Figures 1 to 8 To illustrate the basic principles and several example embodiments of the present disclosure herein.

[0020] Figure 1 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 should be understood that Figure 1The computing device / server 100 described in the foregoing is for illustration only and does not limit the functionality and scope of the embodiments of the present disclosure in any way. The computing device / server 100 can be a computer or a server.

[0021] like Figure 1 As shown, 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 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 performs various processes based on programs stored in memory 120. In a multi-processor system, multiple processing units may execute computer-executable instructions in parallel to increase the parallel processing capabilities of computing device / server 100.

[0022] The computing device / server 100 typically includes various computer storage media. Computer storage media can be any media accessible to the computing device / server 100, including but not limited to volatile and non-volatile media, or removable and non-removable media. The memory 120 can 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.

[0023] like Figure 1 As shown, the memory 120 may include a program 125 for implementing memory compression and block allocation according to an embodiment of the present disclosure. The program 125 may have one or more program modules configured to execute the methods and functions of the various embodiments described herein. In some embodiments, the memory 120 may include a traditional conventional memory (such as an uncompressed memory) and a compressed memory proposed according to an embodiment of the present disclosure. The compressed memory may have a new data layout and block allocation mechanism, which may be used to store compressed data that may be infrequently or infrequently accessed.

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

[0025] The computing device / server 100 may also include additional removable / non-removable or volatile / non-volatile storage media. Figure 1Not shown, but a magnetic disk drive is provided for reading from / writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from / writing to a removable non-volatile optical disk. In this case, each drive is connected to the bus (not shown) via one or more data media interfaces.

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

[0027] Input devices 150 may include one or more input devices, such as a mouse, keyboard, trackball, etc. Output devices 160 may include one or more output devices, such as a display, speakers, printer, etc. Computing device / server 100 may also communicate with one or more external devices (not shown) via communication unit 140, such as a storage device or display device, one or more devices that enable a user to interact with computing device / server 100, or any device that enables computing device / server 100 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface (not shown). Next, with reference to Figures 2 to 8 to describe in detail example embodiments of the present disclosure.

[0028] Figure 2 2 shows an example architecture 200 with tile-based compressed memory according to an embodiment of the present disclosure. Figure 2 As shown, the architecture 200 includes a CPU 210, a memory controller 220, an uncompressed memory 231, a compressed memory 232, and a software application 240. The CPU 210 may be a processing unit for executing program instructions, such as Figure 1 The processing unit 110 is shown. The memory controller 220 is a digital circuit that manages the flow of data to and from the uncompressed memory 231 and the compressed memory 232. The memory controller can be a separate chip or integrated into another chip, such as placed on the same die or as an integral part of the CPU 210. The memory controller can manage read and write operations to the memory while keeping the memory active by supplying current to the memory.

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

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

[0031] According to the example architecture 200, the CPU 210 can transfer data to the uncompressed memory 231 or the 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.

[0032] Figure 3 FIG. 3 is a flow chart showing 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 implemented by reference to FIG. Figure 1 The memory 120 of the computing device / server 100 described or referenced Figure 2 The described compression memory 232 or memory controller 220 may be used for execution.

[0033] At 302, a read request for a memory is received, and the read request is associated with a sub-segment of a segment in the memory. In an embodiment of the present disclosure herein, the compressed memory is divided into a plurality of segments, and each segment may have a first predefined size (such as 32 KiB) and may be referred to as a "tile," where the memory may have a capacity of 4 GiB, for example. Assuming a compression ratio of 2:1 for the compressed memory, 4 GiB of compressed memory may store 8 GiB of uncompressed data.

[0034] In the embodiments of the present disclosure herein, each segment is divided into multiple sub-segments, and each sub-segment can have a second predefined size (such as 512 bytes) and can be called a "paragraph". Each sub-segment in the uncompressed data space is compressed into one or more blocks in the compressed data space, and each block can have a third predefined size (such as 64 bytes). It should be understood that although example sizes of memories, tiles, paragraphs, and blocks are described in some embodiments, other sizes are also possible, depending on manual configuration by the developer and / or administrator. A tile is a self-contained data structure of a fixed size that includes a root entry, a block, and a bitmap. It should be understood that although embodiments of the present disclosure use the terms "tile" and "paragraph" to represent the concepts "segment" and "sub-segment", other terms or words can also represent the concepts "segment" and "sub-segment".

[0035] At 304, an entry corresponding to a sub-segment in the segment is determined, and the entry includes an indicator (such as one or more pointers). In some embodiments of the present disclosure, the entry may be located in the root of the tile as part of the self-contained data structure of the tile, and the entry may also be referred to as a "root entry". For example, the corresponding root entry is first determined based on the first-level address mapping between the paragraph and the entry. In some embodiments, the first-level address mapping may be a fixed mapping rule, and the mapping rule may include a static mapping between the paragraph and the root entry within the tile. Once the paragraph is known, the corresponding root entry may be located within the specific tile to be accessed. In this way, the storage overhead of the root entry may be reduced compared to dynamic mapping. In some embodiments, the fixed mapping rule may be configured in an interleaved manner. For example, the last few bits of the paragraph address are used as the index of the root entry so that continuous paragraphs are widely distributed. In this way, overflow events in the tile may be reduced or better handled. Alternatively, the fixed mapping rule may be a linear mapping (for example, continuous paragraphs have similar compression ratios) or a random mapping (such as a CRC32 algorithm).

[0036] At 306, one or more blocks storing compressed data associated with the read request are determined based on the indicator in the entry. For example, one or more corresponding blocks can be determined based on the second-level address mapping between the root entry and the one or more blocks. The second-level address mapping can be a dynamic mapping rule that includes a dynamic mapping between the root entry and the one or more blocks. In this way, fast block allocation can be achieved. According to the method 300 of the present disclosure, by using two-level address mapping, the size of the entry can be reduced, thereby achieving lower metadata overhead and saving memory space. In addition, since compressed memory can store more data than uncompressed memory, embodiments of the present disclosure can reduce memory costs and / or increase memory capacity.

[0037] In some embodiments, if the determined root entry includes two or more pointers, two or more corresponding blocks are determined, and compressed data can be read from the two or more blocks in parallel. In this way, data blocks can be retrieved in parallel, thereby increasing the read speed of the compressed memory. That is, after reading the root entry, the second level of blocks can be determined, and multiple block reads can be issued in parallel to reduce latency.

[0038] Furthermore, since a root entry can include multiple pointers, multiple blocks can be determined from a single entry. That is, a paragraph can be compressed into many blocks, for example, 1 block, 2 blocks, 4 blocks, 8 blocks, etc. In this way, by making the paragraph size larger than the block size, multiple blocks can be allocated to store compressed data from a single paragraph, thereby reducing internal fragmentation.

[0039] Figure 4 FIG4 shows a schematic diagram 400 of two-level address mapping for tiles according to an embodiment of the present disclosure. Figure 4 As shown, the compressed memory includes a plurality of tiles, such as tiles 410, 420, etc., and address mapping of paragraphs in the tiles to blocks is implemented by two-level address mapping, wherein the root entry serves as an indirection of the two-level address mapping.

[0040] refer to Figure 4 , the tile 410 may include a plurality of root entries (such as the root entry 411), a plurality of blocks (such as blocks 412 and 413), and a bitmap (such as the bitmap 414), the root entry being used to locate the corresponding block, the block being used to store compressed data, and the bitmap being used to indicate the allocation status of the blocks in the tile 410. For example, each bit in the bitmap 414 may indicate whether each block in the tile 410 is allocated. Figure 4 In the example of FIG, first, a paragraph in a tile is mapped to a root entry (such as root entry 411) based on a fixed mapping, as shown by arrow 416, where each paragraph corresponds to a 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 shown by arrows 417 and 418. By limiting the dynamic mapping to tiles, the allocation of blocks in the compressed memory can be stable and fast.

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

[0042] Figure 5 A schematic diagram 500 is shown 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, for example, 32 KiB in size, the unit of compression in the uncompressed data space is a paragraph of, for example, 512 bytes in size, and the unit of memory access in the compressed data space is a block of, for example, 64 bytes in size. In this example, the size of a paragraph is preset to, for example, eight times that of a block. In this way, by increasing the size of each paragraph, the compression ratio of memory compression can be improved because larger compression units generally have a greater compression ratio than smaller compression units.

[0043] refer to Figure 5 , each tile may be divided into multiple sections, such as sections 510 and 520, and sections may be data objects viewed by processors and applications. Figure 5 As shown, paragraph 510 in the uncompressed data space can 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 can be compressed into three blocks in the compressed data space, such as blocks 521, 522, and 523. Figure 5 As shown, different data can have different compression ratios, depending on the type of data and the actual content in the data. In other words, the actual number of blocks depends on the compression ratio of the individual paragraphs.

[0044] Figure 6 An example data layout 600 in a tile 610 according to an embodiment of the present disclosure is shown. As shown, the tile 610 includes a plurality of root entries 620 (such as root entries 621 and 622), a plurality of data blocks 630, and a bitmap 640. In the example data layout 600, the size of the tile 610 can be, for example, 32 KiB, the size of each paragraph is 512 bytes, and the size of each block is 64 bytes.

[0045] In the above example, tile 610 has a total of 512 blocks. Assuming that the compression ratio is preset to 2:1, tile 610 can have 128 paragraphs and 128 root entries. Each root entry can include up to 8 pointers, and the size of each pointer is 9 bits. In this way, each paragraph can correspond to a root entry of up to 9 bytes in size, and 128 paragraphs will occupy 128*9 bytes of memory space (corresponding to 18 blocks), and each paragraph can be compressed into up to 8 blocks. The bitmap 640 is used to control the allocation of blocks in the compressed memory. The 512 blocks in tile 610 will require 512 bits, and 512 bits correspond to 1 block. Therefore, tile 610 has 18 blocks for storing root entries and 1 block for storing the bitmap, which takes up a total of 19 blocks for storing metadata, so the remaining 493 blocks are used to store compressed data, such as Figure 6 In this way, the memory utilization can be improved.

[0046] refer to Figure 6 , bitmap 640 indicates that some blocks are allocated while other blocks are not allocated, where bit "1" indicates that the corresponding block has been allocated. If a write request is received for tile 610, bitmap 640 will first be checked to allocate one or more blocks to store compressed data, and then the corresponding root entry will be written with the ID of the allocated block, and bitmap 640 will also be modified. If a read request is received for a section in tile 610, the corresponding root entry (such as root entry 621) will first be determined based on the first-level fixed mapping, and then the relevant blocks (such as 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 quickly, thereby improving the storage efficiency of the compressed memory.

[0047] Figure 7 FIG. 7 is a flow chart of a method 700 for writing compressed data according to an embodiment of the present disclosure. Figure 3 Compared to the processing of the read request of the tile in the method 300, the method 700 describes the processing method of the write request to the memory. It should be understood that the method 700 can be referred to as Figure 1 The memory 120 of the computing device / server 100 described or referred to in Figure 2 The described compression memory 232 or memory controller 220 may be used for execution.

[0048] At 702, upon receiving a write request to memory in compressed memory, an address translation from a tile to a root entry is performed. For example, the address translator may calculate a root entry address in the compressed memory space based on a physical address in the uncompressed memory space.

[0049] At 704, the bitmap for the tile is checked, and each bit in the bitmap indicates whether each block in the tile is allocated. At 706, based on the bitmap, a determination is made as to whether there are sufficient blocks in the tile for the write request. If the bitmap indicates that there are sufficient blocks in the tile for the write request, then at 708, the 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 also written and updated, and the compressed data is successfully stored in the compressed memory.

[0050] If the bitmap indicates that there are not enough blocks in the tile available for the write request, then at 708, it is necessary to find another tile in the memory that has enough blocks available for the write request. In this case, this means that the blocks in the tile have been consumed and an overflow event has occurred. Then, at 714, at least a portion of the compressed data associated with the write request is written to one or more blocks in another tile. 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 conventional root entry can be used to represent an overflow root entry, and the special value is followed by a pointer to reference another block in the overflow tile. The block in the overflow tile can be used as a root entry to reference the compressed data block in the overflow tile. In some embodiments, another special value (e.g., 0) can be used to indicate an empty root entry, which means that the segment is not allocated or all bits of the memory content are zero.

[0051] Figure 8 An example hardware architecture 800 for implementing memory compression according to an embodiment of the present disclosure is shown. Figure 8 An example of the present disclosure being implemented in a memory controller is shown; however, embodiments of the present disclosure can also be implemented in compressed memory. The example hardware architecture 800 can be a field programmable gate array (FPGA) board attached to a host computer via a peripheral component interconnect express (PCIe) bus. A hypervisor maps the FPGA's PCIe memory-mapped I / O (MMIO) space to software, allowing the CPU to directly access compressed memory. Furthermore, the CPU can also directly access uncompressed memory.

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

[0053] The cache / buffer 831 stores segments that are being read / written or recently accessed, and it can serve two purposes. First, the cache / buffer 831 finds conflicting read / write operations on the same segment and queues them into the FIFO of each segment so that the operations can be executed sequentially. The cache / buffer 831 only performs independent read / write operations on the rest of the memory controller 830, so inconsistencies caused by concurrent operations can be avoided. Second, the cache / buffer 831 caches recently accessed segments to alleviate the access amplification problem. Since the CPU access granularity (cache line size or instruction word size) is usually smaller than the segment size, the CPU will issue multiple read / write operations when scanning the segment sequentially. By using a cache, the compressed blocks of the segment do not need to be loaded and decompressed from DRAM multiple times, thereby reducing overhead.

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

[0055] The write controller 832 receives write requests from the cache / buffer 831 and calculates the root entry address in the compressed memory space based on the address in the write request. The write controller 832 then accesses the root entry and bitmap, determines the block offset within the tile, and calculates the block address in the compressed memory space. The write controller 832 modifies the data based on the write request and then feeds the data to the compression engine. After compression, one or more blocks are allocated or de-allocated from the block allocator based on changes in the compressed data size. Finally, the compressed data is written to the blocks within the tile.

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

[0057] The block allocator manages a bitmap for each tile. To speed up allocations, the block allocator maintains an internal bitmap cache to cache the bitmaps of recently accessed tiles and tiles with a large number of free blocks. For deallocations, the corresponding bit is set to zero. For allocations, it first loads the bitmap for the corresponding tile. If there are sufficient free blocks, the corresponding bit is set. Otherwise, it checks the bitmap cache for an overflow tile with sufficient free blocks. If no such tile is found, it scans the bitmaps across multiple tiles and reports an allocation failure if no overflow tile is found.

[0058] The functions described herein may be performed, at least in part, by one or more hardware logic components. For example, and not 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), system-on-chip systems (SOCs), complex programmable logic devices (CPLDs), and the like.

[0059] The program code for executing the disclosed method can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code causes the function / operation specified in the flow chart and / or block diagram to be realized when executed by the processor or controller. The program code can be executed entirely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0060] In the context of the present disclosure, a machine-readable medium can be any tangible medium that can contain or store a program used by an instruction execution system, device or equipment or used in combination with it. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium will include an electrical connection with one or more wires, a portable computer floppy disk, 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.

[0061] In addition, although operations are described in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown or in sequence, or requiring that all operations shown be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details have been included in the above discussion, these should not be interpreted as limitations on the scope of this disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single implementation. On the contrary, the various features described in the context of a single implementation may also be implemented in multiple embodiments individually or in any suitable subcombination.

[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 for a memory, wherein the memory is divided into a plurality of segments, one of the plurality of segments is divided into a plurality of sub-segments, and one of the plurality of sub-segments is compressed into one or more blocks, the read request being associated with a sub-segment of a segment in the memory; determining an entry corresponding to the sub-segment in the segment, wherein the entry includes an indicator; and determining a block storing compressed data associated with the read request based on the indicator in the entry.

[0064] In some embodiments, determining the entry corresponding to the sub-segment in the segment comprises determining the entry corresponding to the sub-segment based on a mapping rule, wherein the mapping rule comprises a static mapping within the segment between sub-segments and entries.

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

[0066] In some embodiments, determining a block storing compressed data associated with the read request based on the indicator 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 a subsegment and the size of a block, and a size of a pointer in the entry is determined based on a second ratio between the size of a segment and the size of a block.

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

[0068] In some embodiments, the method may further include: receiving a write request to the memory; in response to receiving the write request, checking a bitmap in a segment, wherein the segment includes multiple entries, multiple blocks and the bitmap, and each bit in the bitmap indicates whether each block in the segment is allocated; in response to the bitmap indicating that there are sufficient blocks in the segment available 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.

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

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

[0071] In some embodiments, wherein the method is implemented in the memory, and the read request for the sub-segment of the segment in the memory is received via a memory controller.

[0072] In another aspect, a memory is provided. The memory includes a memory chip and a controller configured to perform an action. The action includes: receiving a read request for the memory chip, wherein the memory chip is divided into a plurality of segments, one of the plurality of segments is divided into a plurality of sub-segments, and one of the plurality of sub-segments is compressed into one or more blocks, and the read request is associated with a sub-segment of a segment in the memory; determining an entry corresponding to the sub-segment in the segment, the entry including an indicator; and determining a block storing compressed data associated with the read request based on the indicator in the entry.

[0073] In some embodiments, determining the entry corresponding to the sub-segment in the segment comprises determining the entry corresponding to the sub-segment based on a mapping rule, wherein the mapping rule comprises a static mapping within the segment between sub-segments and entries.

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

[0075] In some embodiments, determining a block storing compressed data associated with the read request based on the indicator 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 a subsegment and the size of a block, and a size of a pointer in the entry is determined based on a second ratio between the size of a segment and the size of a block.

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

[0077] In some embodiments, the action may also include: receiving a write request to the memory; in response to receiving the write request, checking a bitmap in a segment, wherein the segment includes multiple entries, multiple blocks and the bitmap, and each bit in the bitmap indicates whether each block in the segment is allocated; in response to the bitmap indicating that there are sufficient blocks in the segment available 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.

[0078] In some embodiments, the action may also include: in response to the bitmap indicating that there are not enough blocks in the segment available for the write request, determining another segment in the memory that has enough available blocks; and writing at least a portion of the compressed data associated with the write request to one or more blocks in the another segment.

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

[0080] In another aspect, a program product is provided. The program product includes executable instructions that, when executed on a device, cause the device to perform actions. The actions include receiving a read request for a memory, wherein the memory is divided into a plurality of segments, one of the plurality of segments is divided into a plurality of sub-segments, and one of the plurality of sub-segments is compressed into one or more blocks, the read request being associated with a sub-segment of a segment in the memory; determining an entry in the segment corresponding to the sub-segment, the entry including an indicator; and determining a block storing compressed data associated with the read request based on the indicator in the entry.

[0081] In some embodiments, determining the entry corresponding to the sub-segment in the segment comprises determining the entry corresponding to the sub-segment based on a mapping rule, wherein the mapping rule comprises a static mapping within the segment between sub-segments and entries.

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

[0083] In some embodiments, determining a block storing compressed data associated with the read request based on the indicator 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 a subsegment and the size of a block, and a size of a pointer in the entry is determined based on a second ratio between the size of a segment and the size of a block.

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

[0085] In some embodiments, the action may also include: receiving a write request to the memory; in response to receiving the write request, checking a bitmap in a segment, the segment including multiple entries, multiple blocks and the bitmap, and each bit in the bitmap indicates whether each block in the segment is allocated; in response to the bitmap indicating that there are enough blocks in the segment available 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.

[0086] In some embodiments, the action may also include: in response to the bitmap indicating that there are not enough blocks in the segment available for the write request, determining another segment in the memory that has enough available blocks; and writing at least a portion of the compressed data associated with the write request to one or more blocks in the another segment.

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

[0088] Although the disclosure has been described in language specific to structural features and / or methodological acts, it is to 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.

[0089] The description of the various embodiments of the present disclosure is presented for the purpose of illustration, but 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. A method for memory compression, comprising: receiving a read request for a memory, the memory being divided into a plurality of segments, a segment of the plurality of segments being divided into a plurality of sub-segments, a sub-segment of the plurality of sub-segments being compressed into one or more blocks, and the read request being associated with a sub-segment of a segment in the memory; determining, in the one of the plurality of segments, an entry corresponding to the one of the plurality of subsegments, the entry comprising an indicator, the determining the entry comprising determining the entry corresponding to the one of the plurality of subsegments based on a first mapping rule, the first mapping rule comprising a static mapping within the one of the plurality of segments between the plurality of subsegments and entries; as well as A block storing compressed data associated with the read request is determined based on the indicator in the entry and based on a second mapping rule, the second mapping rule comprising a dynamic mapping between the entry and the block. 2 . The method according to claim 1 , wherein the size of a sub-segment is preset to be at least eight times the size of a block.

3. The method of claim 1 , wherein determining a block storing compressed data associated with the read request based on the indicator in the entry comprises: Two or more blocks associated with the read request are determined based on two or more pointers in the entry, a maximum number of pointers in the entry is determined based on a first ratio between the size of a subsegment and the size of a block, and a size of a pointer in the entry is determined based on a second ratio between the size of a segment and the size of a block.

4. The method according to claim 3, further comprising: In response to determining two or more blocks associated with the read request, reading the compressed data from the two or more blocks in parallel; as well as The compressed data is decompressed to generate decompressed data.

5. The method according to claim 1, further comprising: receiving a write request to the memory; In response to receiving the write request, checking a bitmap in a segment, the segment comprising a plurality of entries, a plurality of blocks, and the bitmap, and each bit in the bitmap indicating whether each block in the segment is allocated; In response to the bitmap indicating that sufficient blocks in the segment are available 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 One or more entries in the bitmap and the segment are updated.

6. The method according to claim 5, further comprising: In response to the bitmap indicating that there are not enough blocks in the segment available for the write request, determining an additional segment in the memory having enough available blocks; as well as At least a portion of the compressed data associated with the write request is written to one or more blocks in the further segment.

7. The method of claim 5, wherein infrequently accessed data is migrated to a compressed memory and frequently accessed data is migrated to an uncompressed memory, and the uncompressed memory and the compressed memory share the same address space accessible from a processor.

8. The method of claim 1, wherein the method is implemented in the memory and the read request for the sub-segment of the segment in the memory is received via a memory controller.

9. A memory comprising: memory chips; as well as A controller is configured to perform actions, the actions comprising: receiving a read request for the memory chip, the memory chip being divided into a plurality of segments, a segment of the plurality of segments being divided into a plurality of sub-segments, a sub-segment of the plurality of sub-segments being compressed into one or more blocks, and the read request being associated with a sub-segment of the segment in the memory; determining, in the one of the plurality of segments, an entry corresponding to the one of the plurality of subsegments, the entry comprising an indicator, the determining the entry comprising determining the entry corresponding to the one of the plurality of subsegments based on a first mapping rule comprising a static mapping within the one of the plurality of segments between the plurality of subsegments and entries; and A block storing compressed data associated with the read request is determined based on the indicator in the entry and based on a second mapping rule, the second mapping rule comprising a dynamic mapping between the entry and the block.

10. The memory according to claim 9, wherein a size of one sub-segment is preset to be at least eight times the size of one block.

11. The memory of claim 9 , wherein determining a block storing compressed data associated with the read request based on the indicator in the entry comprises: Two or more blocks associated with the read request are determined based on two or more pointers in the entry, a maximum number of pointers in the entry is determined based on a first ratio between the size of a subsegment and the size of a block, and a size of a pointer in the entry is determined based on a second ratio between the size of a segment and the size of a block.

12. The memory of claim 11, wherein the actions further comprise: In response to determining two or more blocks associated with the read request, reading the compressed data from the two or more blocks in parallel; as well as The compressed data is decompressed to generate decompressed data.

13. A program product comprising executable instructions that, when executed on a device, cause the device to perform actions comprising: receiving a read request for a memory, the memory being divided into a plurality of segments, a segment of the plurality of segments being divided into a plurality of sub-segments, a sub-segment of the plurality of sub-segments being compressed into one or more blocks, and the read request being associated with a sub-segment of a segment in the memory; determining, in the one of the plurality of segments, an entry corresponding to the one of the plurality of subsegments, the entry comprising an indicator, the determining the entry comprising determining the entry corresponding to the one of the plurality of subsegments based on a first mapping rule, the first mapping rule comprising a static mapping within the one of the plurality of segments between the plurality of subsegments and entries; as well as A block storing compressed data associated with the read request is determined based on the indicator in the entry and based on a second mapping rule, the second mapping rule comprising a dynamic mapping between the entry and the block.

Images